CODEWITHSUNDEEP
gitversion-control
Bill Door
Bill Door

Reputation: 18916

How to manage release branches

We are trying to manage multiple release branches using git. Our branch organization is typical. Primary on-going development is on master. Topic branches are used for work and merged into master. Master is the next major release. However we also work on interim releases (dot releases). For example, master will be working towards version 7.4 while we are also working on 7.3.2.

Naturally, most (all?) of the work done for 7.3.2 must be in 7.4. That is most, of the work done for the 7.3.2 release branch must also be done for the master (ie 7.4) release branch.

What are some techniques that you use to manage these branches? In particular, ensuring that changes are merged into both branches?

Our solution has been to create parallel topic branches. Once a topic has been completed on one or the other of the release branches, it is copied to another topic branch from the other release branch, using cherry-pick or rebase --onto or sometimes even a manual diff and merge.

This process covers the mechanics. How do others ensure that the mechanics actually occur? How do you verify that a change has been made to both (many) release branches?

Thanks for your suggestions

Upvotes: 0

Views: 1014

Answers (2)

Adam Dymitruk
Adam Dymitruk

Reputation: 129526

we use this branch-per-feature work flow:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

nothing is stopping you from doing the same per major release. Feel free to contact me via the comments there or directly on Google+ chat if you need more clarity.

Upvotes: 0

tpg2114
tpg2114

Reputation: 15100

It depends on how many pushes you expect, but we have our Git repos hooked up to Trac and the ticket system there. We've written some custom hooks for Git (which I can share if you would like) that force commit messages to follow a particular format, including citing tickets. Trac handles the rest by posting the commit messages on the tickets. No ticket reference, pushes are rejected. So absolutely everything has to have a ticket associated with it.

We also have the ticket changes emailed to several people. If a push comes in and only goes on one branch when it should go on others too, one of the ticket monitors (who are senior developers with OCD) will go and reopen/pester the person who made the push until it shows up on all the appropriate branches.

The mechanics of how the commits end up on different branches is up to the developer. Some like cherry-pick'ing, others rebasing, others patches. I don't care how it gets there so long as all the branches that need the commit get it!

Upvotes: 0

Related Questions