The desire to enable parallel development is the primary reason that branching and merging was created. Parallel development is a practice which enables development teams working on different areas of the same software project to work simultaneously while minimizing the chance of conflicting changes, thus minimizing wasted effort due to rework or defect resolution. This is the method Team Foundation Server adopts for simplifying the concurrent development. But the main reason we are using Branching and Merging are keep the latest deliverable source during the development process, reduce the risk of impact for deliveries and simplify the project management.
What is Branching and Merging?
Team Foundation Server defines branching as a feature that allows a collection of files to evolve in two or more divergent paths. Branching is unique in that it’s the only isolation mechanism that provides for collaboration amongst a group of people and versioning of changes within that isolated space. Team Foundation Server branches in "path space," which is analogous to copying a folder in Windows Explorer. However, unlike copying, branching maintains the history relating the source to the target to allow merging future changes.
Merging is the logical corollary to branching in Team Foundation Server. Merging in version control is the process of combining changes that have transpired in two distinct branches. A merge operation takes changes that have occurred in the source branch and integrates them into the target branch. Merging integrates all types of changes in the source branch including name changes, file edits, file additions, file deletions, and undeletions. The merge engine is able to do this because Team Foundation Server keeps a record of all changes including the relationships of a child branch to the parent branch. If items are modified in both the source and target branches, a version conflict will be filed and you will be prompted to resolve those conflicts. Once you have created a branch, moving changes from the source branch to the target branch or from the target branch back to the source branch is very easy. Team Foundation Server maintains the relationships of branched items and the merge history.
Do you know how to merge branches?
In Scrum, each Sprint has a retrospective meeting at the end of the Sprint, the product owner will decide if he accepts the Sprint or decline. Once a Sprint has done and the Product Owner has accepted the Sprint, you have to merge your source to the main trunk and branch a new repository for your new Sprint. This work needs to be done before anyone starts coding on the new Sprint. As the new Sprint should use the new branch as the source control. There should be no problems with this process and it should take no longer than 30 minutes.
1. Merge from “$/[Client]/[Project]/DEV/Main” into “$[Client]/[Project]/DEV/[Sprint]”.
This step merge the changes from Main branch into the latest Sprint. You must choose to merge the latest version of Main branch but not any ChangeSet.The merge process collects all the necessary information especially the changes and the merge will be staged in your local workspace. That means it wont directly merge the changes on the server side but needs to perform a check-in operation to commit the changes to the server. This gives you a chance to rollback the operation.
Right-click on Main branch and select “Branching and Merging… | Merge…”.
In the first screen of Source Control Merge Wizard, make sure you choose Main branch as the Source Branch, and last Sprint as the Target branch.
We are going to merge with the latest version of the source. So, choose “Latest Version” in the Version Type(it’s the default option).
Click Finish button to start the Merge process.
There always should be no changes if you don’t have two Sprints at the same time. As the Main branch only contains the latest deliverable source and won’t change until the current Sprint are merged back to Main branch.
2. Merge from “$/[Client]/[Project]/DEV/[Sprint]” into “$[Client]/[Project]/DEV/Main”.
This merge is the big one. When you branch the new Sprint from the Main branch, then you committed all your deliveries to the new Sprint repository. At the end of the Sprint, all the tasks have been done, the changes need to be committed to the latest deliveries once the it has accepted by PO. That means all the work in this Sprint will be merged into Main branch, it’s a considerable changes which depends on the workload of this Sprint.
Right-click on Sprint 2 branch and select “Branching and Merging… | Merge…”. Make sure it’s the opposite direction against the last step. Sprint 2 should be the Source branch, Main is the Target branch, as we want to merge the changes from Sprint 2 back to Main branch.
Click Next button to start the merge process. The merge process examines the changes between two branches, and put all the changes to Main branch in your local workspace.
Once the Merge process completes, you can see the changes from Merge process in Source Control Explorer which are flagged with “merge, branch”.
3. Perform a file and contents diff between your local “Main” folder and “$/[Client]/[Project]/DEV/[Sprint]” (This is a verification step)
Right click on the Sprint Name(here is Sprint2), and select Compare menu.
In the Folder Difference explorer below, you can see the summary information from the top section. “371 files compared: 0 different, 0 only on server, 36 only on local disk”. Ok. You are ready to go! As there are no difference between server and local except some extra files on the local, so you are ready to commit your changes to the Main branch.
But what are those extra local files? In order to make sure you commit the accurate changes and don’t miss any files, it’s better to go through the list to see if there anything missing. In this case, all of them are local debugging files, so we are happy to keep them locally but not on the server.
4. Check in all merged changes on “$/[Client]/[Project]/DEV/Main”
In the last step, you have already merged all the changes back to Main with your latest versions, but all the changes are staged on your local workspace. A check-in needs to be performed to commit all the changes to the Main branch. Right click on Main, and select Check In Pending Changes. We strongly recommend you to put any comments for this check-in as this is a main change.
We also recommend you to use Gated Check-in for Main branch, this will shelve your changes to the server and do a Team Build with your changes. It only allows to check in the changes while Team Build completes successfully. Refer to Team Build 2010 – Gated Check-in for more information about Gated Check-in.
5. Fix any problems with the integration.
Now you have already committed your changes and queued a new Team Build on the server. It should be no problem to pass the Team Build and commit the changes, as the source committed to Sprint 2 has already passed the Team Build. I would say Yes in most cases. But sometimes, you still have to fix something in order to make the Team Build successfully. Otherwise, your changes are still shelved but not committed.
6. Delete this branch
The purpose of the deletion is to make sure it simplify your project management. If there are no concurrent Sprint, it should only have two branches that one is Main which contains the latest deliverable source, and the other one is the current Sprint. This brings you a simple view of the source control structure as well as neat view of the team queries when you connect with Visual Studio 2008. (The problem of connecting with Visual Studio 2008 is it doesn’t show the queries as a tree view.)
Do the followings to delete the branch.
- Set all “SSW.SqlDeploy_Sprint2.XXX” build definitions “Trigger | Select one of the following check-in triggers” to “Manual”
- Delete all build instances
- Delete “$/SSW/SqlDeploy/DEV/Sprint2” branch
- Check-in.
Delete branch is not necessarily if your organization wants to keep the last Sprint for a while. But it’s a best practice to delete this Sprint and then branch a new Sprint from the Main branch. The reason why we don’t delete the build definitions for last Sprint is we want reemploy them for the new branch.
Create a new Branch.
Now, we are going to create a new branch for the new Sprint, this will be the new repository for the new Sprint which already contains all the latest deliverable source.
1. Create a new branch from “$/[Client]/[Project]/DEV/Main” to “$/[Client]/[Project]/DEV/[Sprint]”.
Right-click on Main branch and select “Branching and Merging… | Branch…”.
In the Branch from Main screen, give a name of the Target Branch Name and then click Branch button to perform a branch from Main.
2. Check in the new Branch.
3. For each Build definition
- Rename build defenition “SSW.SqlDeploy_Sprint2.XXX” to “SSW.SqlDeploy_Sprint3.XXX”
- Change the build definitions “Workspace | Working folders | Source Control Folder” to point at the “$/SSW/SqlDeploy/DEV/Sprint3” folder
- Change the build definitions “Process | 1. Required | Items to Build | Projects to Build” to “$/SSW/SqlDeploy/DEV/Sprint3/SSW.SqlDeploy.sln”
- Change the build definitions “Process | 2. Basic | Automated tests | 1. Test Assembly | TestSettings File” to “$/SSW/SqlDeploy/DEV/Sprint3/TraceAndTestImpact.testsettings”
- Test build
4. You are ready to go with the new Sprint.
Notes: Hope this helps you understand branching and merging. Feel free to contact me if you find anything incorrect or unclear. Forgiving me the bad English. Cheers!
