"Go pick" usage of branches and labels on TFS

Reference Path: http://blog.csdn.net/cxzhq2002/article/details/8518250

When to use a branch: for example, a special version that is customized for a customer is very different from the features of the trunk. No need for versatility.

Large revisions, such as 2.0 to 3.0, add a lot of features, but 2.0 also have maintenance. Bug fix

When to use Tags: small version of the release, such as 2.1.1 to 2.1.2.

Advantages of branching: clear, easy to operate, programmer just get Latest/checkin latest.

Disadvantages of branching: merging is cumbersome, and the workaround is either to synchronize periodically or simply not to sync.

Advantages of Tags: flexible

The disadvantage of the label: If you want to hotfix a label version, it is cumbersome to operate, first get specific version by label, and then modify the code, checkin will produce a new changeset, Then in a workspace inside get labelversion, then get Changset, re-label a version. To publish the hotfix. After the release of the previous latest code to copy a copy, re-check in latest

========================================

To branch strategically

Source code is an important asset in the development effort. but how to effectively manage and evolve source files when multiple developers are working on file updates at the same time becomes a challenge. You can use the version control system to store source code in a shared repository, isolate parallel development efforts, integrate code changes, and restore previous file versions. one of the key elements in version control is branching, which can be developed synchronously using branches. If you branch strategically, you can maintain the order and consistency of multiple versions of the software.

Team Foundation provides a flexible and reliable version control system. You can use Team Foundation versioning to manage multiple versions of the development of source code, documents, work items, and other critical information that is handled by the team. For more information about versioning in Visual Studio Team Foundation Server, see Using version control.

How does the team manage code when multiple changes are introduced at the same time through multiple project publications?

When using a version control system, you must consider how to set up the branch structure. You can create a branch by mirroring the source code file. You can then change the branch without affecting the source. For example, as the branching structure shows, the MAIN branch contains the completed functionality that has passed the integration test, and the development Branch contains the code that the team is building. When the new functionality in the development branch is complete and the integration test is available, you can promote the code from the Development Branch to the MAIN branch. This process is called "Reverse integration." Conversely, if you merge the code from the MAIN branch into the development branch, this process is called forward integration.

For more information about how to create and merge code branches, see the following pages on the CodePlex Web site: Team Foundation Server Branching Guide 2.0 (Team Foundation Server Branch 2.0).

Branching and merging need to follow these guidelines:

1. Each branch must have a defined policy that is related to how to integrate code into the appropriate branch. For example, in a branching structure, you can specify a team member to own and manage the MAIN branch. This member is responsible for performing the initial branch operation, reversing the changes from the development branch to the main branch, and integrating the changes from the main branch forward to the development branch. forward integration is important when the MAIN branch also integrates changes from other branches.

2. The MAIN branch must contain code that has passed the integration test so that it is always ready for publishing.

3. Because team members check in changes periodically, the development (or work) branch continues to evolve.

4. A label is a snapshot of a file in a branch at a specific time.

   For more information, see Using tags to get a snapshot of a file.

With Team Foundation build, you can choose from several types of builds for a branch: manual, Continuous, closed, scrolling, and scheduled. It is recommended that the MAIN branch have a gated check-in build type. This means that the development branch must pass all the requirements of the MAIN branch before you can commit the reverse integration. the development branch should run a continuous build type because the team must know as soon as possible when the new check-in that affects the development branch occurs.

What frequency should the team use for reverse integration and forward integration?

As shown, reverse integration and forward integration should be done at least when the user story is complete. Although each team may have different definitions for completion, completing a user story usually means that the functionality and the corresponding unit tests are complete. You can only reverse-integrate the unit tests after verifying the stability of the development Branch into the MAIN branch.

If you have more than one work (that is, the development) branch, you should immediately integrate into all work branches when any branch is integrated into the MAIN branch. because the MAIN branch remains stable, the forward integration is secure. Some conflicts or failures may occur in the work branch because there is no guarantee that the work branch is stable.

It is important that all conflicts be resolved as soon as possible. by using gated Check-in for the main branch, you can make reverse integration much easier, because quality requirements can help avoid conflicts or errors in the main branch. For more information, see Check in a folder that is controlled by the gated check-in build process.

How does the team manage the sources that implement different user stories?

As shown, you can periodically check the changes into a work branch to complete the user story. You can implement multiple user stories at the same time in the same branch, but only when all the work in progress is complete can you reverse integrate to the MAIN branch. It is recommended that you group user stories by similar size, because you do not want large user stories to block the integration of multiple small user stories. You can split two sets of user stories into two branches.

when should the team add branches?

You should create a branch in the following situations:

• When the code must be published in a different timesheet/cycle than the existing branch.

• When the code requires a different branching strategy. If you create a new branch with a new policy, you can add policy value to the project.

• When a feature is published to a customer and the team intends to make changes that do not affect the scheduled release cycle.

You should not create a branch for each user story, as this results in higher integration costs. Although branching is convenient, the overhead of managing a branch can be significant when there are many branches.

from a version control perspective, how does the team manage publishing?

The team should be able to publish the code at the end of any sprint. by using Team Foundation Server, you can mark a branch to take a snapshot of your code at a specific point in time. As shown, you can mark the MAIN branch for the publication. This allows you to return the branch to its state at this point in time.

Because updates must be implemented at release time, creating a branch for a publication helps the team continue to handle the next sprint independently, without conflict with future releases. shows a branch that contains the update code, which is then reverse-integrated into the MAIN branch after it is published at the end of the second sprint.

When you create a branch for a publication, you should create a branch from the main branch, which is the most stable branch. If you branch a publication from a work branch, it can cause integration problems because the stability of the work branch cannot be guaranteed.

Http://msdn.microsoft.com/zh-cn/library/ee782536.aspx

Http://msdn.microsoft.com/zh-cn/magazine/gg598921.aspx

==================

The label is logically

The branches are physical.

Label historical version comparison, in the modification, the middle do emergency release inconvenient, multi-task concurrency, multi-team cooperation has problems, a version of the client.

Branches can be published at any time on the main line, fix the emergency bug, the special edition does not affect the main line, the client multiple versions, easy to confuse.

The role of labels and branches: large versions differentiate.

tags in the appearance of hotfix, concurrent tasks, staff holiday home, the situation of large team work is indeed not good.

"Go pick" usage of branches and labels on TFS