This section details the capabilities of Branching and Merging. The examples in this section were made using the Extensions library.
From the Team Explorer menu, select the “Branches” option. In the Branches menu, select “New Branch”.
Selecting "New Branch" opens the following submenu. Enter the name of the new branch in the required textbox and select "Create Branch." The new branch will appear in the repository map below, and you will automatically be transferred to the new branch. When working within the branch, all changes made are only applied to the branch. Branches can be abandoned or merged into the master branch. Until the branch is committed, it exists locally. To add the branch to the online repository, return to the Team Explorer home menu and select “Sync." In the sync menu select “Push."
Committing to the branch follows the same procedure as committing to the repository. Commits made before the creation of additional branches are made to the “Master” branch. Simply follow the instructions in “Step 4: Committing to the repository," shown above.
In the Team Foundation Services website, it is possible to compare branches of a repository. In the image below, the master branch is labeled as the default branch, as well as the baseline branch for any comparisons. The star marks it as the default branch. The red garbage icon contains the button to delete the TestBranch. There is also a “More Actions” button that appears only on mouseover.
The image above displays the “More Actions” button. When clicked, the menu to the right gives you the option to:
The final options, Branch Policies and Branch Security, allow users to determine the rules for interacting with the branch. The Policies option can make any commit require automated checks before allowing the changes to be applied to the branch. The Security option allows valid users to change the access controls that apply to users of the branch.
For this section, the comparison branch is set to the Master Branch and the “More Actions” option is applied to TestBranch. To begin the comparison, the “Compare Branches” option is selected. In the comparison, there are two tabs that switch between comparing the commits applied to each branch, and comparing the files within the branches. Below is the commit history tab of the branch.
The commit history allows the user to change the commit history type. The four types are:
The history table shows the first eight characters of the commit hash, the associated comment, the author, and the date of the commit.
In the comparison tab, the user can compare the code differences between the currently selected branch and the branch selected as the comparison branch.
Using the Team Explorer in Visual Studio, users can merge branches. From the Team Explorer home page, select the “Branches” option to enter the branches menu. Select “Merge” from the options at the top to open the merge menu displayed to the right. In the menu, the top branch is the branch that we are merging changes from, and the bottom branch is the branch that the user is currently working on. This means that before the user can merge changes from a branch that they have been working on, they must change to the branch that they need to merge into. The checked box labeled “Commit changes after merging” means that any changes will be automatically be staged and added to a local commit.
By default, pull requests only pull the branch that the user is currently working on. To pull from a branch that was created by a different user, the following procedure must be followed. First, select “Branches” in the Team Explorer Home Menu. Right click on the branch that needs to be pulled and select “Checkout” at the top of the menu. This will pull that branch and switch the user to that branch.
Each repository under development will have two main branches, a Master branch and a Development branch. The Master branch is the current published state of the repository. When it is updated, the contents of the Master branch needs to be published as an update. The Development branch will be used by the development team. Features are added to the Development branch.
The Master Branch contains the version of the code that is published to customers. When it is updated, the code needs to be published as an update for customers. Branches require management approval to be merged into the Master branch. Work should never be made directly on the Master branch.
The Development Branch contains the most up to date functioning build. This is the branch that feature branches are merged into. All merges must be able to build and test successfully before they are committed. The Development branch is merged into the Master branch when it is time for a new release. Work is made directly on the Development branch when it is minor changes to existing code. For all other work, a Feature branch should be created.
Feature branches are created whenever a new feature is being added to the repository. They are to be named with the developer and the name of the feature or the type of change being made. Feature Branches must be able to build and test successfully before they are merged to the Development Branch.
Hotfixes are created by being copied from the Master Branch to perform immediate maintenance. These branches are created by developers to fix reported or detected problems in the deployed build. Once they are completed, they must be approved by management and then merged into the master branch for immediate deployment.