the question is should we use branches nowadays?
Well about half year ago I was assigned to perform a study to answer that question. Here's the summary, based on references studied (listed below)
- there's no commonly agreed "best" branching strategy applicable to any project
- most resources seem to agree that choosing productive strategy depends on the particular project specifics
- side note. Based on above it looks like any changes to project branching strategy need to be tested, measured and compared to other options tested
- popular opinion is that merging with Subversion takes a lot of efforts. All who compared SVN and Git note that merging is critically easier with Git
- an important factor seem to be whether production releases originate from trunk or branches. Teams doing prod releases from trunk (which seem to be not quite a popular way) are essentially prohibited to use unstable trunk strategy. Teams doing prod releases from branches have more branching options to choose from.
- popular strategies seem to be stable trunk, unstable trunk and development (integration) branch
...Deciding on the best branching strategy is a balancing act. You must trade off productivity gains against increased risk. One way to validate a chosen strategy is to consider a scenario of change. For example, if you decide to align branches with the system architecture (for example, a branch represents a system component) and you expect significant architectural changes, you might have to restructure your branches and associated processes and policies with each change. Choosing an inadequate branching strategy can cause process overheads and lengthy integration and release cycles that prove frustrating for the whole team...
...Frequent, incremental integration is one of the signposts of success, and its absence is often a characteristic of failure. Current project management methods tend to avoid strict waterfall models and embrace the spiral-like models of iterative/incremental development and evolutionary delivery. Incremental integration strategies, like Merge Early and Often and its variants, are a form of risk management that tries to flush out risk earlier in the lifecycle when there is more time to respond to it. The regularity of the rhythm between integrations is seen by [Booch], [McCarthy], and [McConnell] as a leading indicator of project health (like a "pulse" or a "heartbeat").
Not only does early and frequent integration flesh out risk sooner and in smaller "chunks," it also communicates changes between teammates...
...In most source control systems, you can create hundreds of branches with no performance issues whatsoever; it's the mental overhead of keeping track of all those branches that you really need to worry about... Branching is a complex beast. There are dozens of ways to branch, and nobody can really tell you if you're doing it right or wrong...
...There are many aspects of a system to be considered when branching your code... In the end, the goal is to provide a sandbox for the context in which code is being written. Understanding the available options, when each option is best suited to the situation at hand and the cost of these options will help you in deciding how and when to branch...
Note given other references listed here, author's claim that "This article describes three key branching models used in Software Engineering projects" does not look justified. Terminology used does not look widespread (EFIX, Model-1,2,3 etc).
Reference presents an interesting example of difficulties communicating branching strategies.
...Keep it simple. Working directly off the trunk is by far the best approach in my opinion.
It almost sounds like heresy when I actually type it onto my screen, but if you'll bear with me for a moment, not only will I show you why I think this is essential for an Agile process, but I'll show you how to make it work...
...If I had to base my reasoning on one solid argument, it would be the value of continuous integration. I blogged about the value of CI and best practices in the past. I am a pretty big advocate of CI...
...You really have to ask yourself a question here: "Is all the overhead you are incurring from doing your complicated branching and merging strategy resulting in a real value that does not exist over a more simple strategy?"...
...A strategy I have effectively used in the past and have developed over time. I'll sum it up briefly here.
- Everyone works off of trunk.
- Branch when you release code.
- Branch off a release when you need to create a bug fix for already released code.
- Branch for prototypes.
...Finally, remember that there is no ideal branching and merging strategy. It pretty much depends on your unique development environment...
...The worst case scenario is that you introduce a "semantic merge" problem, where the result of an automated merge is incorrect, but compiles OK and sneaks past testing, possibly even surviving long enough to be a customer-visible bug. Eek!
Adding insult to injury, because they can escape detection longer, semantic merge problems are harder to fix later, since the change is no longer fresh in the mind of the developer who originated the change. (It's usually best to merge changes soon after there made, ideally by the developer who originated the change if that's practical)...
Community members share different experience in various projects using various branching strategies. No agreed consensus on "best" or "worst".
Essentially a brief summary of stuff presented in http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
...There are three common approaches for deciding when and how to branch:
- Create the release branch when you are "feature complete," and plan to fix last-minute issues on this code line. In this case, the release branch is really a "release-prep code line," as described in Software Configuration Management Patterns, since you expect that there is still work to be done.
- Change your work style to avoid final integration work, working off of the active development line.
- Branch for the new work by creating a task branch and merging that work into the active development line after the release is complete.
...A rationale for branching is to isolate code at the end of a release so that it can stabilize. Isolation through branching often masks a quality problem that will end up manifesting itself in the added cost of maintaining parallel streams before a product is released. Branching is easy. Rather, it's the merging and the cognitive overhead of understanding how changes flow between branches that are difficult, so it's important to choose a process that minimizes the cost of branching and merging...
http://nvie.com/posts/a-successful-git-branching-model/ Git-oriented strategy.
...We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the "integration branch". This is where any automatic nightly builds are built from....
...project policies vary widely concerning exactly when it's appropriate to create a feature branch. Some projects never use feature branches at all: commits to /trunk are a free-for-all. The advantage to this system is that it's simple—nobody needs to learn about branching or merging. The disadvantage is that the trunk code is often unstable or unusable. Other projects use branches to an extreme: no change is ever committed to the trunk directly. Even the most trivial changes are created on a short-lived branch, carefully reviewed, and merged to the trunk. Then the branch is deleted. This system guarantees an exceptionally stable and usable trunk at all times, but at the cost of tremendous process overhead.
Most projects take a middle-of-the-road approach. They commonly insist that /trunk compile and pass regression tests at all times. A feature branch is required only when a change requires a large number of destabilizing commits. A good rule of thumb is to ask this question: if the developer worked for days in isolation and then committed the large change all at once (so that /trunk were never destabilized), would it be too large a change to review? If the answer to that question is "yes," the change should be developed on a feature branch. As the developer commits incremental changes to the branch, they can be easily reviewed by peers.
Finally, there's the issue of how to best keep a feature branch in "sync" with the trunk as work progresses. As we mentioned earlier, there's a great risk to working on a branch for weeks or months; trunk changes may continue to pour in, to the point where the two lines of development differ so greatly that it may become a nightmare trying to merge the branch back to the trunk.
This situation is best avoided by regularly merging trunk changes to the branch. Make up a policy: once a week, merge the last week's worth of trunk changes to the branch...
...This section of the Eclipse CVS tutorial is based on Paul Glezen's article on the Eclipse website: Branching with Eclipse and CVS, and is used with his permission under the terms of the EPL license. The changes I am making to his version are mainly to expand it with more step by step images and explanations, and integrate it with my own beginner tutorials in an attempt to make it more accessible to beginners and designers. Experienced developers will probably prefer to work from Paul's version...
...Here are some of the common branching models:
- Branch-by-release Model: One of the most common branching strategies is to align branches with product releases. A branch holds all the software development assets for a single release. Occasionally, updates need to be merged from one release to another, but they usually never merge. Branches will be discontinued when a release is retired.
- Branch per Promotion: Another very common approach is to align branches with software asset promotion levels. A specific development version is branched off into a Test branch, at which all the integration and system testing is performed. When you complete testing, the software development assets are branched into the Production branch and ultimately deployed.
- Branch per Task: To avoid overlapping tasks (or activities) and a loss in productivity, you can isolated them on a separate branch. Keep in mind that these are short-term branches that should be merged as soon as the task is completed, for otherwise the merging effort required may exceed the productivity benefits of creating them in the first place.
- Branch per Component: You could align each branch with the system architecture. In this strategy, you branch off individual components (or subsystems). Then each team developing a component decides when to merge their code back into the development line that serves as the integration branch. This strategy can work well if system architecture is in place and the individual components have well-defined interfaces. The fact that you develop components on branches enables more fine-grained control over software development assets.
- Branch per Technology: Another branching strategy aligned with the system architecture. In this case the branches are aligned to technology platforms. Common code is managed on a separate branch. Due to the unique nature of the software development assets managed on the branches, they probably never merge...
...Refer to the branching and merging guidelines in "Source Control Guidelines" in this guide for a summary of branching and merging guidelines.
...When branching, consider the following:
- Do not branch unless your development team needs to work on the same set of files concurrently. If you are unsure about this, you can label a build and create a branch from that build at a later point. Merging branches can be time consuming and complex, especially if there are significant changes between them.
- Structure your branch trees so that you only need to merge along the hierarchy (up and down the branch tree) rather than across the hierarchy. Branching across the hierarchy requires that you use a baseless merge, which requires more manual conflict resolution.
- The branch hierarchy is based on the branch parent and branch child, which may be different than the physical structure of the source code on disk. When planning your merges, keep in mind the logical branch structure rather than the physical structure on disk.
- Do not branch too deeply. Because it takes time to execute each merge and resolve conflicts, a deep branching structure can mean that changes in a child branch may take a very long time to propagate to the main branch. This can negatively impact project schedules and increase the time to fix bugs.
- Branch at a high-level and include configuration and source files.
- Evolve your branching structure over time.
- Merging requires one or more developers to execute the merge and resolve conflicts. The merged source must be thoroughly tested because it is not uncommon to make bad merge decisions that can destabilize the build.
- Merging across the branch hierarchy is especially difficult and requires you to manually handle many conflicts that could otherwise be handled automatically.
The decision whether to create a branch can be reduced to whether the cost of merging conflicts in real time is higher than the overhead cost of merging conflicts between branches...
discussion of the best practice for release isolation branch strategy in the case of evolving systems.
"Microsoft Team Foundation Server Branching Guidance" - huge and detailed document with recommendations tailored to different projects: HTML version here. Proves that Microsoft does not believe in one-size-fits-all approach wrt branching strategies.
What is the best branching strategy to use when you want to do continuous integration?
...The answer depends on the size of your team and quality of your source control and the ability to merge correctly complex change sets...
more detailed analysis of branching interplay with continuous integration, based on concrete experience with Hudson/Jenkins - along with a couple of useful references
...My greatest discovery was that although CI is about committing, pushing and getting feedback often (i.e. the CI cluster provides you with feedback that your workstation could never give you in the same amount of time), the true purist CI actually has one more requirement — that the team needs to work on the same baseline...
...CVS and SVN were discouraging the whole branching/merging strategy since they were totally unable to do so...
...Simple rule: create a task branch for every new feature or bugfix you've to implement... It can sound like overkill for SVN/CVS users but you know any modern SCM will let you create branches in a second, so there's no real overhead.
Important note: if you look at it carefully you'll see that I'm talking about using task branches as rich-man changelists...
...Branching policy is influenced by the development objectives of the project and provides a mechanism to control the evolution of the code base. There are as many variations of branching policy as organizations that use Rational ClearCase version control. But there are also similarities that reflect common adherence to best practices...
...The Subversion model (or general open source model more accurately) is what is being shown in the unstable trunk model...
In the field of software development, trunk refers to the unnamed branch (version) of a file tree under revision control. The trunk is usually meant to be the base of a project on which development progresses. If developers are working exclusively on the trunk, it always contains the latest cutting-edge version of the project, but therefore may also be the most unstable version. Another approach is to split a branch off the trunk, implement changes in that branch and merge the changes back into the trunk when the branch has proven to be stable and working. Depending on development mode and commit policy the trunk may contain the most stable or the least stable or something-in-between version.
Often main developer work takes place in the trunk and stable versions are branched, and occasional bug-fixes are merged from branches to the trunk. When development of future versions is done in non-trunk branches, it is usually done for projects that do not change often, or where a change is expected to take a long time to develop until it will be ready for incorporating in the trunk...
...These are notes from a webinar on Subversion best practices, conducted Aug. 30, 2006 by CollabNet.
...Two organizational strategies: unstable trunk vs. stable trunk...
...PREFER an unstable trunk when possible...
In SVN, trunk is the recommended place for the main development and I use this convention for all of my projects. However, this means that trunk is sometimes unstable, or even broken...
...wouldn't it be better to do the "wild development" on some branch like /branch/dev and only merge to trunk when the build is reasonably solid?
- ...The trunk is where the ongoing development is supposed to happen. You really shouldn't have a problem with "broken" code, if everyone is testing their changes before committing them. A good rule of thumb is to do an update (get all the latest code from the repos) after you have coded your changes. Then build and do some unit testing. If everything builds and works, you should be good to check it in...
- ...Nope trunk isn't the best place. At our organization we always follow this approach: Trunk contains release code, so it always compiles. With new each release/milestone we open a new branch. Whenever a developer owns up an item, he/she creates a new branch to this release branch and merges it into a release branch only after testing it. Release branch is merged into trunk after system testing...
...I used to work on the trunk because for all the projects I worked on, it's either I was the sole developer or the team ensured that everyone code check-in has passed the local tests. Otherwise, we created (we still) branches for bug fixes, large code for new features, etc.
About 2 months ago, I had a short git session with Kamal and he shared with me the idea of story/branch. And as my team started to grow with more dev guys, I feel the need of encouraging more branching and now this has become a rule. For a project with automated tests defined with CI set up, a stable trunk is guaranteed and this practice can fit very well into it.
We don't use git but Subversion because that's how we started and we are still comfortable with it now (most of the time)...
This is part of an online book called Source Control HOWTO, a best practices guide on source control, version control, and configuration management...
...Eric's Preferred Branching Practice ...Keep a "basically unstable" trunk. Do your active development in the trunk, the stability of which increases as you approach release. After you ship, create a maintenance branch and always keep it very stable...
...In the next chapter I will delve into the topic of merging branches...
Starting mail of the thread discussing branching strategies for Apache Forrest project
- note currently the project appears to use unstable trunk model with release branches:
- "Development work is done on the trunk of SVN... There are "release branches" of SVN, e.g. forrest_07_branch." (project guidelines)
- "Building the release candidate packages... 17. Create a maintenance branch in SVN..." (How to release)
O'Reilly CVS branching docs:
- ...The basically stable branching philosophy states that the trunk should contain project data that is always close to being ready for release...
...More lenient variations of this philosophy allow anything that passes developer unit-testing to be merged into the trunk. Such a relaxed approach requires a release candidate to be branched off and put through a full QA analysis before publication...
- ...The basically unstable philosophy states that the trunk should contain the latest code, regardless of its stability, and that release candidates should be branched off for QA.
...More lenient variations also allow branching for experimental code, refactoring, and other special-case code. Merging of a branch back into the trunk is done by the managers of the branch. ...
- Note above resource did not appear in any of the searches I performed (CVS related guidelines aren't popular anymore?)
Best practices in SCM (perforce article) at
...six general areas of SCM deployment, and some coarse-grained best practices within each of those areas. The following chapters explain each item...
Workspaces, Codelines, Branching, Change Propagation, Builds, Process...