Git branching strategy for long-running unreleased code

Question

At our team, in addition to individual units of work (Stories), we have longer-running themes of work (Epics). Multiple stories make an epic.

Traditionally we've had feature branches for each Story, and merged those straight to master when they pass QA. However, we'd like to start holding back on release of completed stories in an Epic until the Epic is deemed "feature complete". We'd only release these features to production when the entire Epic is closed. Furthermore, we have a nightly build server - we'd like all closed Stories (including those that are part of incomplete Epics) to be deployed to this nightly server automatically.

Are there any suggestions on how to manage our repo to achieve this? I've considered introducing "epic branches", where we'd merging closed stories to the related epic branch instead of direct to master, but my concerns are:

• I worry about the merge conflicts that may arise if epic branches are kept open for long
• Nightly builds would require merging all epic branches into a "nightly build" branch. Again, merge conflicts could arise, and this is to be done automatically

Answer 1

Simple suggestion: don't do that.

git branches are not for long-running forks of the code, as discussed here and here. Branches are best treated as transient things used to organize commits by an individual developer on a day-to-day level. So if they have a name that corresponds to something a project manager (let alone end user) might care about you are doing something wrong.

Recommended practice is to use continuous integration with feature toggles or branch-by-abstraction to ensure that:

• all code is integrated at all times (at least every day, preferably more often)
• what gets deployed is under explicit control.

Answer 2

This is a tricky problem but one that many people face. I prefer using the Gitflow setup as a starting point.

Development -> New stuff being worked on
Master -> Finished stuff needing testing Production -> Stuff that has been published to production.

At minor (shorter) features I create a branch from development do the work there then merger the branch back to development.

At major (long term) features I create a branch from development, create smaller branches from that branch, then merge back to the first branch. Once the major feature is complete then back into development branch it goes.

At regular intervals (depends on project) I merge development back into master and a testing cycle begins. If any fixes come up in testing they are done in the master branch (sub branch then merge in). And development can continue on the master branch during testing.

At any time master should be merged into development, and development should be merged to any of it's long term sub branches.

master should always (in theory) be ready for production. Development should always (in theory) be ready for production. The only reason there is a difference it to provide a solid set of features for testers to test.

When ready, a commit in master that is tested is merged in to production and deployment in production happens from that branch. HOTFIXs that need to be done in an emergency can then take place on Production branch without having to merge in master (which may have many un-tested changes).

My normal Tree looks like

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production  

It is my general rule that no single change should take more then a few hours. If it does then it needs to be made into smaller changes. If it's a huge feature (like a UI re-write) then that goes in long term so that normal development can continue at the same time. LongTerm branches are normally only local branches while Development, Master, and Production are remote branches. Any sub branches are also local only. This keeps the repository clean for others, without loosing the usefulness of git on a long term feature set.

I would like to note, however, that the existence of a long term branch is a rare thing. Normally, all my work is in development. Only when I have a feature (set) that is going to take so long that I need to be able to work on normal dev stuff too, do I use the LongTerm branch. If it's just a set of changes that should be together then I just don't merge to master till there all done.

Answer 3

I think this is a pretty common problem and boils down to choosing which features to include in a release after the features have been coded rather than before.

eg.

I have features A, B and C for v2 of my product. B and C are related, I don't want to release B unless C is also finished.

I have three devs all working at the same time on the features.

I Have a set in stone release date D

B is finished and merged in, A is finished and merged in. C is delayed... what do I do?!

I do not believe there is a technical solution to this problem. You want to release an untested version of the product with only feature A included. Unless you merge and test all possible combinations of features this is always going to be a possibility.

The solution is a more human one. You have missed your release date and must push it back.