Branching as part of source control management is intended for code-separation or code-isolation and it becomes inevitable under the following scenarios
Each team can promote or merge their finished stories to the mainline branch.
When all storied or features are done for a release, then create a label (TFS) or TAG in SVN with the release name.
Ideally, we would create the following branches for efficient code-isolation
- Trunk or Mainline- Stable Code line
- Dev — Feature or Team branch under development
- Release — From which the code is deployed to production
Branch Owner
Each branch will have an appointed branch owner who will be responsible for enforcing branch policy and will be responsible for merging and resolving conflicts.
Trunk or Mainline Branch
The Trunk and Mainline branch is from where the releases are made. This line should never break otherwise the whole idea of having a Team or Feature specific branch will go in vain.
Trunk or Mainline Policy
The name of the Branch will be either Trunk or Mainline
1. Can be released at any time
At any moment, the product owner can decide that we should make a new production release directly from the tip of the mainline. A release branch can be created to proceed with the production release.
2. Want to release ASAP We shouldn’t check-in or merge a finished story to Trunk unless it has to go live (or at least wouldn’t mind if it goes live).
The team branch is for checking in stories that are in progress. This branch is also used to run integration tests before checking in stories to the Trunk and can be used by the Agile or Attached QA to verify the completed stories before it goes to Trunk. The name of the branch will be
Team_A,
Team_B etc. Team Branch Policy
1. Code compiles & builds.
2. All unit tests pass.
The terms Promote and Rebase are tied to the source control tools like Seapine Surround and TFS but whereas SVN and Git uses Merge (upward or downward) extensively.
Rebasing
This is the process of propagating changes from the Trunk to the team development branches. This has to do often, minimum once a day, preferably when the developer starts his day.
1. Every day when a team gets to work, someone (generally the branch owner) in the team is responsible for merging the latest version from Trunk to the team dev branch.
2. If the team discovers a code conflict it has to be resolved immediately — that’s top priority!
3. If the team needs help from other teams or whoever wrote the code that conflicts the team has to go fetch them and work together to sort it out.
4. The important thing is that team is responsible for getting the problem sorted out, and that we need to sort it out on the team dev branch and not on the Trunk.
5. Conflict should be resolved in the branch which is least stable.
6. Rebasing can be done as frequently as possible and not necessarily once a day. But the minimum should be once a day.
The stories that are completed in the team dev branch and ready for production is merged upwards to the Trunk and is termed as Promoting.
Just before the promotion is done a rebase should be done to identify and relsove the conflict, if any.
After the release, based on the Product Road Map, the Product Owner may choose to release Service Pack Release or work on the bug fixes for critical issues, if any, reported by the customer. In the above image, any issues reported on 1.1.0 will be fixed in that branch and release to the customer. After releasing the HotFix 1 for the patch, Release 1.1.1 branch is created. In some cases, if more than 1 HotFix needs to be worked on independently at the same time, the developer can create HotFix specific branch (similar to Team Dev branch) and merge it to the respective release branch before taking it to production.
