Sign in to follow this  
boolean

Git experts - can you sanity check my blog post on branch strategies?

Recommended Posts

Hi guys
 
About 7 months ago I implemented a Git branching strategy at my office (well, technically it was Mercurial, but I've been using it for a Git project recently too) to save us from deployment headaches. It seems to be working well but it goes against a lot of conventional wisdom online because nobody seems to take non-github closed-source projects into account (eg. game development, web development).
 
Would those who are good at Git and source control in general be able to have a quick read and see if there's any edge cases I didn't think of? I want to make sure my reasoning is solid :)
 
If anyone finds flaws in my approach or has any feedback I'd be very appreciative.
 
Thanks guys!
 
Edit - woops, I thought I got alerts when people responded. Didn't realize people had replied to this. Thanks for the responses though. I'll unpub my article for a bit and try and work in the advice posted here. I found a few videos of the BitBucket team that has a similar flow to the way I was proposing, but with some of the issues raised here worked out. I'll see if I can incorporate both. Cheers!
Edited by boolean

Share this post


Link to post
Share on other sites

I think you just shifted the problem.

 

If you do sequential feature development, then a feature B that depends on a previous feature A will break if you take out feature A (ie your disaster scenario).

 

If you do parallel development, the above doesn't happen, but you get the possibility that a feature A and a feature B change the same file from 'master' in different ways, and you get merge conflicts during the merge into QA.

(I didn't see how you propose to handle that)

 

 

Edit: The right thing to do seems to be a revert of the removed feature in the development branch (a reverse merge of feature X). It doesn't avoid the merge conflict, but it's the cleanest way out (for as far as merge conflicts are ever clean).

Edited by Alberth

Share this post


Link to post
Share on other sites

Eh honestly, i'd just make another branch and do what I need to do to "remove feature X", with the feature's original branch around as reference. I dont think using git to add/remove features to your codebase is a good idea. As Alberth said, the interactions between them aren't as clear cut as git's branches.

Share this post


Link to post
Share on other sites

I don't really see much difference between game development and web/app development in terms of how I would like to use source control. If a feature is added, it's intended to be in there permanently. Disabling it for certain releases may be necessary, but that doesn't mean removing it from the build entirely. If a future feature comes to depend heavily on code from a previous feature, that's an issue (or not an issue) that is independent of the version control used to implement those features. I don't think the versioning system is the right place to control these situations.

Share this post


Link to post
Share on other sites

The basic tradeoff here is merge early/often vs merge late/rarely.

 

If features A-D are small, I'd argue "who cares" - cherry picking or temporarily disabling changes is easy enough that I wouldn't bother optimizing my workflow around it.  So let's assume they're large.

 

"Feature D" doesn't get merged with the changes introduced by "Feature A" and "Feature B" until the last minute in your workflow.  Refactoring conflicts will be a real mess to resolve, near impossible to properly review, and impossible to bisect for problems.  I have repeatedly, in the past when faced with such problems, rebased "Feature D" atop "QA" or incrementally merged "QA" into "Feature D".  This makes it much easier to highlight refactoring conflict resolutions that need proper vetting in code reviews, makes the merge much more reviewable, and makes the history bisectable in a useful manner.  Unfortunately, this is basically turning your workflow back into the original one - with all it's problems.  If we suddenly decide Feature B is out, I'm still SOL.  Still, I'd generally rather have those problems than megamerge problems.

 

Maybe your situation is different enough that you'd rather make a different tradeoff somehow?  An alternative option possibly worth mentioning here:  Feature toggles.

 

> If someone in QA notices a bug on the live site, do you create a Hotfix branch from your current master/development branch or the old dead-end release branch?

 

You don't actually solve this conundrum with your workflow any better ;).

 

Hotfixes should generally always be branched from whatever commit is live ("master" here?) to minimize the scope of the hotfix - or the previous unshipped hotfix - and thus reduce the risk that you'll introduce additional bugs that won't be caught by the typical vetting process of soaking in the Dev/QA branch for awhile that you're mostly skipping - and then merged back into "Development" and/or "QA" at your earliest convenience.

 

Speaking of broken CSS: It's impossible to see what text I've selected for copy/paste on Chrome on that site.

 

> Release day! We get news Feature C is being removed.

 

I don't think I've had this happen once in my years of game development.  Occasionally we'll roll back a recent change for stability, but that's about it.  Having *this* late notice sounds weird to me.  Having it happen regularly enough to base your branching strategy around it - well, hey, maybe you do have a use case, but I don't think this is a "closed source" issue per se ;)

Share this post


Link to post
Share on other sites

I'd summarize your post as "we have a limited understanding of how git gets used in production, but here's our solution that works for us in our particular."  It's a good post as far as that goes, and your explanation of it is clear and effective (a very important feature of a workflow). I'd rate you blog post a B.

 

The problem I'd see is you up-front statement about how "open source" uses a DVCS based on a few samples from one commercial git repo provider.  I say that because your problem space then goes on to describe a very very small-scale version of how the Linux kernel -- the project for which git was developed and still one of the largest users and contributors to git itself -- works.  Linux has literally thousands of developers contributing simultaneously to the same areas of code, has regular releases, and has multiple features added and not released each iteration.  How do they handle the situation?

 

I myself work on Free software project with multiple contributors and regularly scheduled releases.  We use git, we use bzr, and some of the upstreams we contribute to used hg.  All DVCSs work pretty much the same.  What we end up using is the continuous integration methodology that became popularized with the "Agile" silver bullet solution a few years ago: the guiding philosophy is "trunk is always publishable."  That means a pull request (using Github terminology: it could be a request to pull, a series of patches in email, or a merge proposal on Launchpad) get built against trunk using the CI service and if approved after a manual review, it gets automerged into trunk.  Releases are done by tagging a specific revision on the trunk.  Branches are done from the trunk, and from time to time get synched to trunk to make sure they remain mergable.  QA (or the design team) also test builds from feature branches, and the entire feature may be rejected before landing; we have infrastructure to automatically create deployable packages from branches for just such QA use.  In reality, we end up having QA test such deployments before they get merged to trunk just to ensure trunk always remains shippable (which gives us 2 levels of QA: per-pull-request and regular sanity testing of trunk, but they do different tests).

 

The projects I work on have between 3 and 30 full-time developers working on them.  We do regularly scheduled releases and maintain old releases for up to 5 years.  Our workflow is simpler than yours.

 

I think your solution is more complicated than it really needs to be for the projects with which I have experience, but may just be the solution for your own particular project culture.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this