<p>When migrating from something to something else, there are only two things you need to define:</p>

<ol>
<li>What is your target</li>
<li>How to get there (the migration plan)</li>
</ol>

<p>The first part is, sadly, often overlooked or <strong>way</strong> too vague. You cannot simply say that what you have is a mess and you want to organize it. What would that mean? Everybody would have a different interpretation (aka: every dev thinks that <em>his</em> or <em>her</em> way of doing things is the best).</p>

<p>Chances are, all the branches you have are serving or have served a purpose. Without a clearly defined target process, people will keep doing what works for them the way it suits them best (and rightly so).</p>

<p>For example, your target should be defined as clearly as Vincent Driessen defined his <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">"successful Git branching model"</a>. If you look at this model, it is very precise: It says where stable code should be, and where unstable features should be developed. It also says how - and when - to branch, update and merge back. You know what each branch is for, and what to do with them. We use a variation of what was put forward by Vincent and our variation is defined in our wiki.</p>

<p>The important point is to have all the team understand and agree on a target. It might be worth it to remind people that you are not looking for their personal favorite branching model, but a model that all the team members can agree on and use easily.</p>

<p>Once you have your target, you'll be able to elaborate you migration plan. That plan can be as long or as short as you'd like. I've seen such branching model imposed overnight; at other places, it was done over 2 or 3 sprints. It doesn't matter much to me, as long as we are improving.</p>

<p>You can start with the "biggest" or more important branches. E.g.: "from now on, master must always be in a state to be deployed in prod and the dev branch must always compile" (or whatever your rules). Then, enforce version (release) branches. Afterwards, enforce feature branches. After that, impose a code freeze on version branch, if it make sense.</p>

<p>DevOps is all about communication, openness and efficiency. These concepts must be kept in mind and communicated throughout the process.</p>

<p>I would suggest to invite some people outside of the development team to the process meeting as observers. Ops or middle management might have a thing or two to say about your model. The developers' needs should be prioritized, but if the branching model is impossible to align with the way things are managed, you'd be better knowing now and not in a month or two.</p>

<p>If you have really big teams, try to include everyone nonetheless. With very big teams, you'll end up with two or three meetings anyway. So invite team leaders in the room, but have a webcast available and let everyone know about it. If anyone has a suggestion or concern, they'll be able to voice it to their team leader and if it is valid, it will be addressed on the second or third meeting.</p>

CC BY-SA 3.0
2017-03-01T05:09:30.393Z
2017-03-02T13:40:48.830Z
2017-03-02T13:40:48.830Z
Alexandre
<p>It is actually very simple to convert a multi-branched hydra repository into a single branched model.</p>

<p>First, you want to start with the branches which have the least difference between itself and master or trunk. Examine their age and relevance. If they are still relevant, start merging them together and resolving conflicts. If they are no longer relevant, then delete them.</p>

<p>Continue this process until you have managed to merge all your branches, resolved all conflicts, and you have only a single branch remaining.</p>

<p>You can follow this simple outline to get started:</p>

<ol>
<li>Create a copy of your master/trunk branch and call it <code>temp_master</code></li>
<li>Find the branch with the greatest divergence from master/trunk.  </li>
<li>Determine if the branch needs to be kept, archived, or deleted.  

<ol>
<li>If it needs to be kept, continue to step 4.  </li>
<li>If it needs to be deleted or archived, delete and archive it, and then return to step 2.</li>
</ol></li>
<li>Repeat step 2 to find the next branch with the least divergence.</li>
<li>Merge the two branches found in step 2 and step 3, resolving all conflicts.</li>
<li>Merge your these two branches into your <code>temp_master</code> branch.</li>
<li>Test the code in temp_master code to see if it compiles, and builds, and run any other automated tests you have for sanity.

<ol>
<li>If any tests fail, go back, find out why, and fix them, and repeat the process.  </li>
<li>If tests still fail, pick two different branches to work with.</li>
</ol></li>
<li>Repeat steps 2 - 7 until you have only two branches, your master/trunk and <code>temp_master</code>.</li>
<li>Finally, merge <code>temp_master</code> into master/trunk and live with your new single-branch model.</li>
</ol>

CC BY-SA 3.0
2017-03-06T09:31:40.050Z
2017-03-06T09:31:40.050Z
avi
<p>Because you mention waterfall, I understand that the numerous branches you are alluding to are feature-branches rather than maintenance-branches.</p>

<p>In this setup, I also assume that these branches are created according to a waterfall plan that tries to minimise conflicts.  This implies that the goal of the development is to produce several distinct products.  When using a single-branch development model, it is important to also work on a single product. If several products are simultaneously developed in a single-branch development model, it effectively “glues” together versions of theses products, so that we might have in version <em>a</em> of the repository a healthy product <em>X</em> and a buggy product <em>Y</em>, while in version <em>b</em> the product <em>X</em> has a regression and <em>Y</em> a bug fix, but we have no version where both <em>X</em> and <em>Y</em> are healthy.  Such a situation would force us to consider <em>X</em> and <em>Y</em> as being developed in distinct repositories, which is a hint that they should be.</p>

<p>Therefore, the first steps should <a href="/q/171">perform a repository split</a>:</p>

<ol>
<li><p>Arrange the repository so that it is easy to split it into several small repositories. For instance, rearrange the current repository so that each top-level directory corresponds to a repository you want to create in the future. Doing so, you can continue to use the <em>branch-spaghetti</em> discipline everybody is familiar with.</p></li>
<li><p>When step 1 is completed, refine the <em>branch-spaghetti</em> discipline by requiring that any single branch can only touch files in one top-level directory.</p></li>
<li><p>When each branch complies with step 2, perform the split. Developers can easily convert their pending changes to patch a single repository, just by removing the first-level of the path.</p></li>
</ol>

<p>Now that the split has been performed, you can start working on the branch discipline itself.</p>

<ol start="4">
<li><p>Introduce programming techniques helping the development of short-lived branches. Branches being short-lived is a crucial aspect of all single-branch methodologies. One of their goals is to reduce the time spent on merging and debugging long-lived branches. A popular technique is the introduction of “feature-flags” where a “factory” uses a configuration flag to either produce the historic version of an object or the new, initially partially developed, version of that object.</p></li>
<li><p>By now, you have zillions of repositories with only a few branches in each, and you can turn the “we globally adopt the trunk-based development discipline” button, without seeing the original <em>branch-spaghetti</em> mountain collapsing on the trunk.</p></li>
</ol>

<p>The actual split of repositories might be optional, but you would then have to adopt policies that cleanly delineate the allowed scope of each submitted patch (to limit the risk of conflicts when merging changes in the main branch). Reducing the overhead bound to conflicts is one of the goals of single-branch model methodologies, so I assume this is relevant in your context.</p>

CC BY-SA 3.0
2017-10-15T19:45:32.093Z
But Google and FB use monorepos with trunk-based...
AnoE
CC BY-SA 3.0
2017-03-01T15:39:03.843Z
correct: those branches are feature and (various levels of) integration branches.
Dan Cornilescu
CC BY-SA 3.0
2017-03-03T18:46:01.040Z
about 1: even after the split, it may be worth mention you can still get a whole spaghetti-like view with the use of repo
ᴳᵁᴵᴰᴼ
CC BY-SA 3.0
2017-03-01T14:53:17.257Z
2017-03-04T12:48:43.667Z
2017-03-04T12:48:43.667Z
Michaël Le Barbier
<p>For large organisations with typical 4 weeks sprint cycle <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">Git-Flow</a> is preferred approach because
You get benefit of Feature branch
Master production ready branch is always deployable
Also, master branch is kept clean from unwanted commits by following two commit cycle (from feature to <code>Develop</code> and <code>Develop</code> branch to Master).</p>

<p>Moreover, branching is also determined by frequency of production releases. For frequent deployment to production its better to have a Feature branch or Centralized model. In this case overhead of managing branches is shifted to robust testing in lower environments to maintain production stability. </p>

CC BY-SA 3.0
2017-03-01T04:27:41.250Z
Can you improve this answer to make it easier to understand?
Evgeny Zislis
CC BY-SA 3.0
2017-03-02T09:04:08.667Z
The question specifically states it is about *the migration/transition itself, not about the before and the after methodologies*.  You seem to be addressing the latter here.
Toby Speight
CC BY-SA 3.0
2017-03-02T16:20:18.803Z
@TobySpeight The question was changed from its original by edits, which is why this answer used to be relevant but no longer is.
Evgeny Zislis
CC BY-SA 3.0
2017-03-01T03:28:55.670Z
2017-03-01T19:28:12.350Z
2017-03-01T19:28:12.350Z
Octonaut
<p>In large organisations, using the waterfall methodology typically results in very complex branching structures (aka <em>branch spagetti</em>).</p>

<p>What branching strategies can be used to transition from a complex branching reality to a single-branch model like trunk-based development?</p>

<p>Update:</p>

<p>To clarify, the question is about the <strong>migration/transition itself</strong>, not about the before and the after methodologies, which are pretty clear. </p>

<p>It can't really be "at EOB today we're still waterfall with gazillion of branches but tomorrow 1st thing we'll switchover to trunk-based, single-branch CI".</p>

CC BY-SA 3.0
2017-03-01T04:43:32.313Z
You can be waterfall and have clearly defined and enforced branching practices or be agile and have a gazillion branches (free-for-all!). One does not imply the other.
Alexandre
CC BY-SA 3.0
2017-03-01T04:47:34.090Z
@Alexandre the question body clarifies the context: transition from many branches to one.
Dan Cornilescu
CC BY-SA 3.0
2017-03-01T05:20:11.220Z
You changed the question completely from the original ... making half of the answers irrelevant.
Evgeny Zislis
CC BY-SA 3.0
2017-03-01T05:31:18.480Z
Hm, I fail to see that. The update is just re-stating that the focus is on what remains *unchanged* in both title ("migration from ... to ...") and body ("in transition to"): http://devops.stackexchange.com/posts/122/revisions. Half of the answers were already irrelevant because they missed that. Which is why I added the clarification.
Dan Cornilescu
CC BY-SA 3.0
2017-03-01T06:02:16.603Z
Hi @DanCornilescu I made my edit after Evgeny comment, so don't try to point it out on me ;)
Your original question had element regarding software development process, branching model and DevOps practices. People gave answers on what they they thought the question was about.
You then modified your question (edit #2: http://devops.stackexchange.com/revisions/122/2) and made some of those answers irrelevant.
Alexandre
CC BY-SA 3.0
2017-03-01T06:11:01.627Z
@Alexandre no worries, I don't do that ;) Thanks for clarifying the question.
Dan Cornilescu
CC BY-SA 3.0
2017-03-01T06:16:13.517Z
@DanCornilescu I'm sorry I missed that the question was specifically about a single-branch model. Thanks for further clarifying the clarification!
Alexandre
CC BY-SA 3.0
2017-03-02T12:04:39.220Z
@DanCornilescu thanks for clarification, you have already specified branching strategy to be single branch model. So question is more of migration strategy.
Octonaut
CC BY-SA 3.0
2017-03-02T13:52:49.237Z
flippant answer -- start merging and deleting branches, eventually, you'll have just one?
avi
CC BY-SA 3.0
2017-03-03T17:52:21.683Z
@avi: yes, that's actually what I had in mind :)
Dan Cornilescu
<continuous-integration><branch><waterfall>
How to transition from a complex branching reality to a single-branch model?
Dan Cornilescu
# How to transition from a complex branching reality to a single-branch model?

(Asked by: username_0 on 2017-03-01)

In large organisations, using the waterfall methodology typically results in very complex branching structures (aka *branch spagetti*).

What branching strategies can be used to transition from a complex branching reality to a single-branch model like trunk-based development?

Update:

To clarify, the question is about the **migration/transition itself**, not about the before and the after methodologies, which are pretty clear.

It can't really be "at EOB today we're still waterfall with gazillion of branches but tomorrow 1st thing we'll switchover to trunk-based, single-branch CI".

**Tags:** continuous-integration, branch, waterfall

> **Comments:**
> **username_1**: You can be waterfall and have clearly defined and enforced branching practices or be agile and have a gazillion branches (free-for-all!). One does not imply the other.  
> **username_0**: @username_1 the question body clarifies the context: transition from many branches to one.  
> **username_2**: You changed the question completely from the original ... making half of the answers irrelevant.  
> **username_0**: Hm, I fail to see that. The update is just re-stating that the focus is on what remains *unchanged* in both title ("migration from ... to ...") and body ("in transition to"): http://devops.stackexchange.com/posts/122/revisions. Half of the answers were already irrelevant because they missed that. Which is why I added the clarification.  
> **username_1**: Hi @DanCornilescu I made my edit after Evgeny comment, so don't try to point it out on me ;) Your original question had element regarding software development process, branching model and DevOps practices. People gave answers on what they they thought the question was about. You then modified your question (edit #2: http://devops.stackexchange.com/revisions/122/2) and made some of those answers irrelevant.  
> **username_0**: @username_1 no worries, I don't do that ;) Thanks for clarifying the question.  
> **username_1**: @DanCornilescu I'm sorry I missed that the question was specifically about a single-branch model. Thanks for further clarifying the clarification!  
> **username_3**: @DanCornilescu thanks for clarification, you have already specified branching strategy to be single branch model. So question is more of migration strategy.  
> **username_4**: flippant answer -- start merging and deleting branches, eventually, you'll have just one?  
> **username_0**: @username_4: yes, that's actually what I had in mind :)  

---

## 4 answers

### Answer by username_5 on 2017-03-01. Score: 11

Because you mention waterfall, I understand that the numerous branches you are alluding to are feature-branches rather than maintenance-branches.

In this setup, I also assume that these branches are created according to a waterfall plan that tries to minimise conflicts. This implies that the goal of the development is to produce several distinct products. When using a single-branch development model, it is important to also work on a single product. If several products are simultaneously developed in a single-branch development model, it effectively “glues” together versions of theses products, so that we might have in version *a* of the repository a healthy product *X* and a buggy product *Y*, while in version *b* the product *X* has a regression and *Y* a bug fix, but we have no version where both *X* and *Y* are healthy. Such a situation would force us to consider *X* and *Y* as being developed in distinct repositories, which is a hint that they should be.

Therefore, the first steps should [perform a repository split](/q/171):

1. Arrange the repository so that it is easy to split it into several small repositories. For instance, rearrange the current repository so that each top-level directory corresponds to a repository you want to create in the future. Doing so, you can continue to use the *branch-spaghetti* discipline everybody is familiar with.
2. When step 1 is completed, refine the *branch-spaghetti* discipline by requiring that any single branch can only touch files in one top-level directory.
3. When each branch complies with step 2, perform the split. Developers can easily convert their pending changes to patch a single repository, just by removing the first-level of the path.

Now that the split has been performed, you can start working on the branch discipline itself.

4. Introduce programming techniques helping the development of short-lived branches. Branches being short-lived is a crucial aspect of all single-branch methodologies. One of their goals is to reduce the time spent on merging and debugging long-lived branches. A popular technique is the introduction of “feature-flags” where a “factory” uses a configuration flag to either produce the historic version of an object or the new, initially partially developed, version of that object.
5. By now, you have zillions of repositories with only a few branches in each, and you can turn the “we globally adopt the trunk-based development discipline” button, without seeing the original *branch-spaghetti* mountain collapsing on the trunk.

The actual split of repositories might be optional, but you would then have to adopt policies that cleanly delineate the allowed scope of each submitted patch (to limit the risk of conflicts when merging changes in the main branch). Reducing the overhead bound to conflicts is one of the goals of single-branch model methodologies, so I assume this is relevant in your context.

> **Comments:**
> **username_0**: correct: those branches are feature and (various levels of) integration branches.  
> **username_7**: about 1: even after the split, it may be worth mention you can still get a whole spaghetti-like view with the use of repo  
> **username_6**: But Google and FB use monorepos with trunk-based...  

---

### Answer by username_1 on 2017-03-01. Score: 6

When migrating from something to something else, there are only two things you need to define:

1. What is your target
2. How to get there (the migration plan)

The first part is, sadly, often overlooked or **way** too vague. You cannot simply say that what you have is a mess and you want to organize it. What would that mean? Everybody would have a different interpretation (aka: every dev thinks that *his* or *her* way of doing things is the best).

Chances are, all the branches you have are serving or have served a purpose. Without a clearly defined target process, people will keep doing what works for them the way it suits them best (and rightly so).

For example, your target should be defined as clearly as Vincent Driessen defined his ["successful Git branching model"](http://nvie.com/posts/a-successful-git-branching-model/). If you look at this model, it is very precise: It says where stable code should be, and where unstable features should be developed. It also says how - and when - to branch, update and merge back. You know what each branch is for, and what to do with them. We use a variation of what was put forward by Vincent and our variation is defined in our wiki.

The important point is to have all the team understand and agree on a target. It might be worth it to remind people that you are not looking for their personal favorite branching model, but a model that all the team members can agree on and use easily.

Once you have your target, you'll be able to elaborate you migration plan. That plan can be as long or as short as you'd like. I've seen such branching model imposed overnight; at other places, it was done over 2 or 3 sprints. It doesn't matter much to me, as long as we are improving.

You can start with the "biggest" or more important branches. E.g.: "from now on, master must always be in a state to be deployed in prod and the dev branch must always compile" (or whatever your rules). Then, enforce version (release) branches. Afterwards, enforce feature branches. After that, impose a code freeze on version branch, if it make sense.

DevOps is all about communication, openness and efficiency. These concepts must be kept in mind and communicated throughout the process.

I would suggest to invite some people outside of the development team to the process meeting as observers. Ops or middle management might have a thing or two to say about your model. The developers' needs should be prioritized, but if the branching model is impossible to align with the way things are managed, you'd be better knowing now and not in a month or two.

If you have really big teams, try to include everyone nonetheless. With very big teams, you'll end up with two or three meetings anyway. So invite team leaders in the room, but have a webcast available and let everyone know about it. If anyone has a suggestion or concern, they'll be able to voice it to their team leader and if it is valid, it will be addressed on the second or third meeting.


---

### Answer by username_4 on 2017-03-06. Score: 3

It is actually very simple to convert a multi-branched hydra repository into a single branched model.

First, you want to start with the branches which have the least difference between itself and master or trunk. Examine their age and relevance. If they are still relevant, start merging them together and resolving conflicts. If they are no longer relevant, then delete them.

Continue this process until you have managed to merge all your branches, resolved all conflicts, and you have only a single branch remaining.

You can follow this simple outline to get started:

1. Create a copy of your master/trunk branch and call it `temp_master`
2. Find the branch with the greatest divergence from master/trunk.
3. Determine if the branch needs to be kept, archived, or deleted.
   1. If it needs to be kept, continue to step 4.
   2. If it needs to be deleted or archived, delete and archive it, and then return to step 2.
4. Repeat step 2 to find the next branch with the least divergence.
5. Merge the two branches found in step 2 and step 3, resolving all conflicts.
6. Merge your these two branches into your `temp_master` branch.
7. Test the code in temp\_master code to see if it compiles, and builds, and run any other automated tests you have for sanity.
   1. If any tests fail, go back, find out why, and fix them, and repeat the process.
   2. If tests still fail, pick two different branches to work with.
8. Repeat steps 2 - 7 until you have only two branches, your master/trunk and `temp_master`.
9. Finally, merge `temp_master` into master/trunk and live with your new single-branch model.


---

### Answer by username_3 on 2017-03-01. Score: -4

For large organisations with typical 4 weeks sprint cycle [Git-Flow](http://nvie.com/posts/a-successful-git-branching-model/) is preferred approach because
You get benefit of Feature branch
Master production ready branch is always deployable
Also, master branch is kept clean from unwanted commits by following two commit cycle (from feature to `Develop` and `Develop` branch to Master).

Moreover, branching is also determined by frequency of production releases. For frequent deployment to production its better to have a Feature branch or Centralized model. In this case overhead of managing branches is shifted to robust testing in lower environments to maintain production stability.

> **Comments:**
> **username_2**: Can you improve this answer to make it easier to understand?  
> **username_8**: The question specifically states it is about *the migration/transition itself, not about the before and the after methodologies*.  You seem to be addressing the latter here.  
> **username_2**: @TobySpeight The question was changed from its original by edits, which is why this answer used to be relevant but no longer is.  

---

