Croyez à l'utopie de simplification des merges et des branches

Nicola Paolucci
Nicola Paolucci
Retour à la liste

Branching workflows go from bare and simple, to complex, robust, and defensive. What is the level of complexity and safeguard needed by your organization? This post covers the compromise between nimbleness and robustness, with some guidelines to choose your own git adventure and lessons learned inside Atlassian.

L'objectif de cet article est de vous donner les informations et les outils nécessaires pour choisir le modèle branching le plus efficace pour votre équipe.


  • Trust the merge
  • Évitez les modèles de branching extrêmes.
  • Simplifiez et aplatissez les hiérarchies de branche dans la mesure du possible
  • Consider how your development process and your tooling impact the branching model decisions

Trust the merge

The first step in choosing the optimal branching model is to trust the merge. I mention this for teams that have only recently adopted git;If you've passed this step and have embraced the merge, skip this paragraph.

While in older systems you could be brought to extreme measures – like avoiding merges at all costs or hire a special team to take care of the merge hell – turns out merges are a non-event in git. This is due to several key things:

  • Because branches are very cheap and fast, git encourages short-lived branches and fast integration.
  • Merges are local in git, hence the result of a merge is often immediate.
  • git knows the ancestry of your branches and only merges the commits that are relevant instead than the entire work-tree flat. This generally results in less conflicts.
  • You have a plethora of merge strategies at your disposal. Because of this you will love to merge and by converse you will also love branching. Branching and merging become so easy that some teams end up with the opposite problem, they go overboard with them. So as with all in life, maintain a balance and don't overdo it.

Stay away from branching extremes

If you look at branching models at large – pre- and post-git advent – you see they sit on a spectrum that goes from simple to layered. Extremes can be problematic. Let me show you a few stops on the branching continuum and why you might want them or not.

Single branch extreme

Memory of subversion past: one branch to rule them all. For years softwareteams (myself included) worked with just one branch, the trunk, in good or bad weather, with finished on unfinished features, with working or broken builds. This process used to work and it works still today. But it's not the most efficient anymore.

Le monde à une seule branche que nous aimions détester, avec lequel nous avons grandi et dans lequel certains d'entre nous travaillent encore ressemble à ceci :


Teams fresh on git adoption or teams that want to retain their workflow might try to reproduce the same feel. Even though the trunk in git-speak is now called master you can work with a single branch in git, it looks like this:

Rebase on feature

Everyone works on master, nobody works on branches and every single developer uses rebase to keep up-to-date with the latest changes. This is very close to an old style trunk-only subversion branching model.

It's not uncommon for me to hear modern teams that - yes - have embraced some level of branching but are nostalgic and enforce a squash on commit rule that flattens history and makes master look exactly as the picture above.

What do they miss? Context and traceability. For more read my piece on the merge vs rebase debate.

What is the major drawback of a single branch? When master is broken the work of everyone is disrupted. It's true that with gitdevelopers have the entire history of the project at their disposal. It is easy to go back in time to before the breakage and keep working until the problem is resolved. But it's true also that if a developer knows how to do this time travel smoothly, he is also using his own local branches to park his work.

Trop de couches sur les branches d'intégration

À l'inverse, il y a une organisation qui adore formaliser les process et qui utilise les branches en se compliquant la vie au lieu de la simplifier.

Examinons par exemple le modèle de branching suivant :

Too many branches

In this example the team creates a branch for each user story, from each user story in turn a branch is created for each issue and from each issue branch a branch is created for each sub-task. Then it all goes into their next branch from which they release to master.

I said it earlier and it's true: branching and merging is painless in git but complicating your process will affect the velocity of your team regardless.

Simplifiez et aplatissez les hiérarchies de branche dans la mesure du possible

Au moins, nous savons à présent que nous devons éviter les extrêmes. Quel est donc le meilleur compromis entre structure et flexibilité ? Trouvez facilement la solution idéale pour votre équipe en répondant à quelques questions fondamentales :

  • De combien de branches longues ai-je besoin au minimum pour prendre en charge mon projet ?
  • Ai-je besoin de maintenir les anciennes versions de mon logiciel ou non ? En général, vous devez essayer d'aplatir les hiérarchies de branche autant que possible, en fonction de la robustesse de votre suite de test, de la confiance et du niveau de responsabilité que vous voulez accorder à votre équipe et de votre tolérance aux problèmes de production.

At Atlassian we use a relatively flat branching model in several of our teams, both for our BTF(behind the firewall) products and our On Demand offering(Cloud). 

One branch per user-story or one branch per issue (Jira issue) ?

The granularity of branches matters. If they are too coarse and force many people working together you run into the single branch problems I highlighted before, if you create (and publish) too many branches, your review process and the overall picture can get confusing and bloated.

We've found that a good granularity in choosing the scope of branches is "One branch per issue".

Sane Workflow #1: Single stable master, leverage branches but keep it simple

My recent article on simple git workflows showed a simple branching model for continuous delivery. Which is centered around the notion that master is the production branch. Any commit to master is a tagged production release. It's a great workflow for example for web applications, store fronts, Saas and in general for situations when you don't have to maintain older historical versions.

Sane Workflow #2: Keep it simple but maintain older releases

When you have to maintain and support older versions of your products a single stable master is not enough. The solution is to have a long running release branches for each version your team needs to support. Changes flow always from the older branches to the more recent ones, never in the opposite direction. For reason why see post on the essence of branch based workflows.

Long running release branches

Branches d'intégration supplémentaires si nécessaire

Provided you know exactly why you can't do without it can be helpful to isolate the work of a small team of developers for longer than a single iteration. To accomplish this you can setup an integration branch. The branch should be updated with the latest from master as often as possible, to simplify the final merge.

For example inside the Bitbucket Server team additional integration branches happen 1-2 times per release cycle - which in their case is around six weeks. Those are needed when the team has multiple streams of work that they need to keep isolated for a bit.

Le process de développement et les outils ont un impact sur le modèle de branching.

Le process de développement et les outils de votre équipe ont une influence considérable sur les décisions relatives au modèle de branching ainsi que sur son agilité et son efficacité.

If you use the Pull Request facilities of Bitbucket Server or Bitbucket Cloud you can review your peers' work directly, without squashing branches to a single commit.

Au final, plus vous disposez d'informations sur le statut et les livrables de vos équipes, plus il sera facile pour tout le monde de travailler en parallèle.

Imaginez que vous puissiez, en un coup d'œil, vous renseigner sur le statut de tous les builds, des pull requests, des branches et des commits d'une fonctionnalité donnée. Excellente nouvelle : ce rêve est devenu une réalité. Appréciez cette merveille :

JIRA development panel

*This development panel is available with Jira 6.2, Bitbucket Server 2.10+, Bamboo 5.4.

What you see above is the 'Development' panel in Jira. When combined with Bitbucket and Bamboo, you have a single place you can go for all your development updates. This panel, available in all your Jira issues and rapid boards, allows everyone in the development cycle to be in sync. Stay on top of the status of your branches, identify the ones with broken builds and monitor their deployments without ever have to dig for information again. Spend time building and releasing great code, instead of tracking it.


This piece went longer than I anticipated but I hope it gives you a good set of guidelines on how to choose an effective and lean branching model for your teams. Follow me @durdn and the awesome @Bitbucket team for more DVCS rocking.

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant