Branching Strategies [closed]

问题:

The company I work for is starting to have issues with their current branching model and I was wondering what different kinds of branching strategies the community has been exposed to?

Are there any good ones for different situations? What does your company use? What are the advantages and disadvantages of them??

回答1:

Here is the method I've used in the past with good success:

/trunk - bleeding edge. Next major release of the code. May or may not work at any given time.

/branches/1.0, 1.1, etc. Stable maintenance branches of the code. Used to fix bugs, stabilize new releases. If a maintenance branch, it should compile (if applicable) and be ready for QA/shipping at any given time. If a stabilization branch, it should compile and be feature complete. No new features should be added, no refactoring, and no code cleanups. You can add a pre- prefix to indicate stabilization branches vs maintenance branches.

/branches/cool_feature. Used for highly experimental or destructive work that may or may not make it into trunk (or a maintenance branch). No guarantees about code compiling, working, or otherwise behaving sanely. Should last the minimum time as possible before merging into the mainline branch.

/tags/1.0.1, 1.0.2, 1.1.3a, etc. Used for tagging a packaged & shipped release. Never EVER changes. Make as many tags as you want, but they're immutable.

回答2:

I'd highly encourage reading Eric Sink's opinion on the matter:

Chapter 7: Branches

I, like Eric, prefer the "folder" style branching that he talks about.

回答3:

For the mother lode on branching patterns see Brad Appleton's Streamed Lines: Branching Patterns for Parallel Software Development. It's heavy duty but I haven't seen anything to surpass it in terms of breadth and depth of knowledge about branching.

回答4:

Our repository looks like:

/trunk
/branches
/sandbox
/vendor
/ccnet

/trunk is your standard, bleeding edge development. We use CI so this must always build and pass tests.

/branches this is where we put 'sanctioned' large changes, ie something we KNOW will make it into trunk but may need some work and would break CI. Also where we work on maintenance releases, which have their own CI projects.

/sandbox each developer has their own sandbox, plus a shared sandbox. This is for things like "Lets add a LINQ provider to our product" type of tasks that you do when you are not doing your real work. It may eventually go into trunk, it may not, but it is there and under version control. No CI here.

/vendor standard vendor branch for projects where we compile but it is not code that we maintain.

/ccnet this is our CI tags, only the CI server can write in here. Hindsight would have told us to rename this to something more generic such as CI, BUILDS, etc.

回答5:

1. One branch for the active development (/main or master, depending on the jargon)
2. One branch for each maintenance release -> it will receive only really small fixes, while all major development goes to /main
3. One branch for each new task: create a new branch to work on every new entry on your Bugzilla/Jira/Rally. Commit often, self document the change using inch pebble checkins, and merge it back to its "parent" branch only when it's finished and well tested.

Take a look at this http://codicesoftware.blogspot.com/2010/03/branching-strategies.html for a better explanation

回答6:

The first thing: KISS (Keep it simple stupid!)

/branches
  /RB-1.0 (*1)
  /RB-1.1 (*1)
  /RB-2.0 (*1)
/tags
  /REL-1.0 (or whatever your version look like e.g. 1.0.0.123 *2)
  /REL-1.1
  /REL-2.0
/trunk
  current development with cool new features ;-)

*1) Keep version maintainable - e.g. Service Packs, Hotfixes, Bugfixes which may be merged to trunk if necessary and/or needed) *2) major.minor.build.revision

Rules of the thumb:

1. The Tags folder need not to be checked out
2. Only few coding in release branches (makes merging simpler) - no code cleanup etc.
3. Never to coding in tags folder
4. Never put concrete version information into source files. Use Place-holders or 0.0.0.0 which the build mechanism will replace by the version number you're building
5. Never put third party libraries into your source control (also no one will add STL, MFC etc. libraries to SVN ;-))
6. Only commit code that compiles
7. Prefer using environment variables instead of hard-coded paths (absolute and relative paths)

--hfrmobile

回答7:

We branch when a release is ready for final QA. If any issues are discovered during the QA process, the bugs are fixed in the branch, validated and then merged to the trunk. Once the branch passes QA we tag it as a release. Any hotfixes for that release are also done to the branch, validated, merged to the trunk and then tagged as a separate release.

The folder structure would look like this (1 QA line, 2 hotfix releases, and the trunk):

/branches

/REL-1.0

/tags

/REL-1.0

/REL-1.0.1

/REL-1.0.2

/trunk

回答8:

We use the wild, wild, west style of git-branches. We have some branches that have well-known names defined by convention, but in our case, tags are actually more important for us to meet our corporate process policy requirements.

I saw below that you use Subversion, so I'm thinking you probably should check out the section on branching in the Subversion Book. Specifically, look at the "repository layout" section in Branch Maintenance and Common Branch Patterns.

回答9:

The alternative I'm not seeing here is a "Branch on Change" philosophy.

Instead of having your trunk the "Wild West", what if the trunk is the "Current Release"? This works well when there is only one version of the application released at a time - such as a web site. When a new feature or bug fix is necessary a branch is made to hold that change. Often this allows the fixes to be migrated to release individually and prevents your cowboy coders from accidentally adding a feature to release that you didn't intend. (Often it's a backdoor - "Just for development/testing")

The pointers from Ben Collins are quite useful in determining what style would work well for your situation.

回答10:

Henrik Kniberg's Version Control for Multiple Agile Teams also has some good points to take into consideration.

回答11:

We currently have one branch for ongoing maintenance, one branch for "new initiatives" which just means "stuff that will come out sometime in the future; we're not sure when." We have also occasionally had two maintenance branches going on: one to provide fixes for what is currently in production and one that is still in QA.

The main advantage we've seen is the ability to react to user requests and emergencies more rapidly. We can do the fix on the branch that is in production and release it without releasing anything extra that may have already been checked in.

The main disadvantage is that we end up doing a lot of merging between branches, which increases the chance that something will get missed or merged incorrectly. So far, that hasn't been a problem, but it is definitely something to keep in mind.

Before we instituted this policy, we generally did all development in the trunk and only branched when we released code. We then did fixes against that branch as needed. It was simpler, but not as flexible.

回答12:

Jeff Atwood wrote about this in a good blog post; that post has got some important links in it.

回答13:

Gnat has written this excellent break down on the various bits of advice your can find on branching strategies.

There's not one branching strategy, it's what works for:

• Your team size
• Your product and the lifecycle periods
• The technology you're using (web, embedded, windows apps)
• Your source control, e.g. Git, TFS, Hg

Jeff Atwood's post breaks down a lot of possibilities. Another to add is the concept of promotion (from Ryan Duffield's link). In this setup you have a dev branch, test bracnh and release branch. You promote your code up until it reaches the release branch and is deployed.

回答14:

The philosophy that we follow at work is to keep the trunk in a state where you can push at any time without drastic harm to the site. This is not to say that the trunk will always be in a perfect state. There will of course be bugs in it. But the point is to never, ever leave it broken drastically.

If you have a feature to add, branch. A design change, branch. There have been so many times where I thought, "oh I can just do this in the trunk it isn't going to take that long", and then 5 hours later when I can't figure out the bug that is breaking things I really wished that I had branched.

When you keep the trunk clean you allow the opportunity to quickly apply and push out bug fixes. You don't have to worry about the broken code you have that you conveniently branched off.

回答15:

This would depend on which Version Control System you're using. Each VCS has different approaches to branching.

Which VSC do you use?

回答16:

For Subversion, I agree with Ryan Duffield's comment. The chapter he refers to provides a good analyses on which system to use.

The reason I asked is that Perforce provides a completely different way to create branches from SVN or CVS. Plus, there are all the DVCSs that give it's own philosophy on branching. Your branching strategy would be dictated by which tool(s) you're using.

FYI, Svnmerge.py is a tool to assist with merging branches in SVN. It works very well as long as you use it frequently ( every 10-30 ) commits, otherwise the tool can get confused.

回答17:

No matter which branching pattern chosen, you should try to keep your branches in a binary tree form like this:

   trunk - tags
     |
    next
   /  \  \
bugfix  f1  f2
        /   \  \          
       f11    f21 f22

• Child nodes should only merge with the direct parent.
• Try ur best to merge only the whole branch with the parent branch. never merge subfolders within a branch.
• You may cherry pick commits when needed as long as you only merge and pick from whole branch.
• The next branch in the above figure is only for illustration, you may not need it.