Sub-tasks for user stories are usually in two broad categories: technical bits that need to be built, and quality activities that need to be performed. For the problem you have of releasing weekly (which, by the way is great!), the most common approach has two main elements:
- Test-Driven Development (TDD) at the technical bits level. By using TDD properly, you ensure that any code that is committed is covered by passing tests and that developers have done a full unit regression run on their development workstations. This is a quality activity that should be included in the tasks for every user story. (Actually, most teams would add this to their definition of done.) I strongly recommend the book "Test Driven Development" by Kent Beck for details on this approach.
- Feature Switches at the user story level. Every user story gets a feature switch configuration parameter. It's "off" in production, but "on" in the development environment for a team until the team has completed the work on the user story. Sometimes implementing feature switches can be challenging if your current work requires changing existing in-production code. Therefore, it is also important for teams to have strong refactoring skills to keep the design of the system as simple as possible.
Please don't implement branch and merge for the teams. This will lead to huge problems as the complexity of your code increases. Even if you just branch for the duration of the Sprint, you will find that more and more time is spent merging at the end of the Sprint to prepare to release to production. Instead, great testing, refactoring and other quality and code-maintenance practices will help you avoid this path. I recommend two books for this: "Continuous Delivery" by Humble and "Working Effectively with Legacy Code" by Feathers.
In general, it sounds like you might not be making effective use of your definition of done. In Sprint Planning, your team can do task breakdown however they like... but by having a common definition of done for all three teams, you will avoid many common pitfalls. The definition of done aught to have some basic items like coding standards (naming conventions, patterns, etc.), testing standards (TDD, acceptance testing, etc.), and quality inspection standards (pairing, code reviews, etc.). Anything in the definition of done doesn't need to be called out as a separate task. Instead, tasks focus on the technical bits that need to be built such as UI layout, business logic and algorithms, database schema changes, integrations, etc. In many ways, good task breakdown is like a mini detailed design activity done during Sprint planning.