In TFS, should I label or create a branch for a pr

问题:

When making a deployment to production, should I mark my code with a label or create a branch for the code that's in production?

回答1:

In TFS, I would have a Release branch with a label identifying the specific version being released to production.

Which would imply you have other branches may I suggest the following

• Three major branches: Main, Develop, & Release.
• One Hotfix branch for your current fire.
• 0 to N Major-Feature branches to contain the disruption of development.

Details

• Main Branch
  • Contains the latest stable builds
  • Tag/Label each release
• Develop Branch
  • Branched from the Main
  • Where most of the work is done
  • Merge back to Main before release
• Release Branch
  • Branched from one of the following:
    • The Develop branch
    • OR the Main branch (this may be better since it is "stable")
  • Bug fixes are done here
  • After fixes are tested and released,
    • merge to Develop branch
    • OR merge to Main branch and then forward integrate (FI - which is a merge from parent to child) to Develop
  • Tag/Label each release or bug fix
• Hotfix Branch
  • Branched from Main
  • Merged back into Main
  • Forward integrate merge to Develop
  • Used to allow Main to remain "stable"
• Major Feature Branches
  • Branched from Develop
  • Merged back into Develop
  • Used for major features that would possibly disrupt the regular development path

References:

• another stack overflow question: when-to-use-a-tag-label-and-when-to-branch especially Martin Woodward's answer
• Source Control How To by Eric Sink
• A successful Git branching model by Vincent Driessen
  • This contains a very good graphic of a branching model

回答2:

Ideally, both.

You probably want to have a label so that you know exactly what you delivered for a specific release. However, you probably also want to create a branch so that you can perform minor bug fixing to what was released and create a new release.

回答3:

In practice, you could approach it in one of two ways:

• Have a continuous developmental timeline that gets branched for each of your production releases:

example:

 ------------------------->dev
     |      |      |
     |      |      |
     |      |      |
    v1.0   v2.0   v3.0

• Have your production releases "cascade" off of one another:

example:

---->v1.0---->v2.0---->v3.0

Ultimately, up to you in deciding what architecture to adopt, as long as it's consistent and makes sense to you.

回答4:

You can use a combination of both. Here is how we do this internally for all projects.

We have structure with folder Branches and sub folder for each minor and major version. We also use labels that we set on individual sub folders so we can easily rebuild any specific version any time in the future.

$\Branches
    \2012.01
    \2012.02 (branched from 2012.01)
    \2012.03 (branched from 2012.02)
    \2013.01 (branched from 2012.03)

You can also check out Visual Studio Team Foundation Server Branching and Merging Guide for more details.

回答5:

I have seen both done, Labeling is more lightweight and to me easier. But, it has been pointed out that labels can be deleted rather easily. A branch protects against this by not actually being deleted unless "destroyed". The reason I prefer not use branches is I hate having to cloak them as I tend to do get latest from the root and don't want all those branches filling up my hard drive

For the record, since it was pointed out to me about label's being deleted I have removed permissions for Labeling from everyone but Admins and the build service accounts to help mitigate this.