For this scenario, Release 1 is the source branch, Release 2 is the target branch, and we want to merge all changes up to a specific version, so we will take the defaults on this page and click Next.
In this window you can select the source and target branches for your merge process, as well as how to specify what changes you want to merge. Source Control Merge Wizard - First Screen. This opens the Source Control Merge Wizard window, shown in Figure 2.įigure 2. In Visual Studio 2010, in Source Control Explorer, right-click on the Release 1 branch, and from the Context Menu select Branching and Merging | Merge. We now need to Forward Integrate, or merge, this bug into Release 2. While testing Release 1, we have found a bug and fixed it on the Release 1 branch. For this scenario, we have moved our Release 1 code into testing, so we have branched our code into Release 2, to allow the developers to continue working on the next release. Let's look at how, building off the branches we made in our previous article, we can implement this merging process. In Figure 1, you can see the general pattern for how bug fixes are merged from one release to the next using the Branch By Release pattern.įigure 1.
In this column we are going to build off the previous column around Branch By Release, by showing how to forward integrate bug fixes, as well as look at some of the different branch visualization options available in Team Foundation Server 2010. , we discussed the theory around Branch By Release, its merging patterns, and how to implement it using Team Foundation Server 2010. Mickey Gousset shows us how to implement Branch By Release merges using TFS 2010, and some new visualization features.īranch By Release using Team Foundation Server 2010 Inside TFS Branch By Release in TFS 2010 - Part 2