What git branching models actually work - the final question
- by UncleCJ
In our company we have successfully deployed git and we are currently using a simple trunk/release/hotfixes branching model. However, this has it's problems, I have some key issues of confusion in the community which would be awesome to have answered here. Maybe my hopes for an Alexander stroke are too great, quite possibly I'll decompose this question into more manageable issues, but here's my first shot.
Workflows / branching models - below are the three main descriptions of this I have seen, but they are partially contradicting each other or don't go far enough to sort out the subsequent issues we've run into (as described below). Thus our team so far defaults to not so great solutions. Are you doing something better?
gitworkflows(7) Manual Page
(nvie) A successful Git branching model
(reinh) A Git Workflow for Agile Teams
Merging vs rebasing (tangled vs sequential history) - the bids on this are as confusing as it gets. Should one pull --rebase or wait with merging back to the mainline until your task is finished? Personally I lean towards merging since this preserves a visual illustration of on which base a task was started and finished, and I even prefer merge --no-ff for this purpose. It has other drawbacks however. Also many haven't realized the useful property of merging - that it isn't commutative (merging a topic branch into master does not mean merging master into the topic branch).
I am looking for a natural workflow - sometimes mistakes happen because our procedures don't capture a specific situation with simple rules. For example a fix needed for earlier releases should of course be based sufficiently downstream to be possible to merge upstream into all branches necessary (is the usage of these terms clear enough?). However it happens that a fix makes it into the master before the developer realizes it should have been placed further downstream, and if that is already pushed (even worse, merged or something based on it) then the option remaining is cherry-picking, with it's associated perils... What simple rules like such do you use? Also in this is included the awkwardness of one topic branch necessarily excluding other topic branches (assuming they are branched from a common baseline). Developers don't want to finish a feature to start another one feeling like the code they just wrote is not there anymore
How to avoid creating merge conflicts (due to cherry-pick)? What seems like a sure way to create a merge conflict is to cherry-pick between branches, they can never be merged again? Would applying the same commit in revert (how to do this?) in either branch possibly solve this situation? This is one reason I do not dare to push for a largely merge-based workflow.
How to decompose into topical branches? - We realize that it would be awesome to assemble a finished integration from topic branches, but often work by our developers is not clearly defined (sometimes as simple as "poking around") and if some code has already gone into a "misc" topic, it can not be taken out of there again, according to the question above? How do you work with defining/approving/graduating/releasing your topic branches?
Proper procedures like code review and graduating would of course be lovely, but we simply cannot keep things untangled enough to manage this - any suggestions?
integration branches, illustration please?
Vote and comment as much as you'd like, I'll try to keep the issue page clear and informative enough. Thanks!
Below is a list of related topics on stackoverflow I have checked out:
What are some good strategies to allow deployed applications to be hotfixable?
Workflow description for git usage for in-house development
Git workflow for corporate Linux kernel development
How do you maintain development code and production code? (thanks for this PDF!)
git releases management
Git Cherry-pick vs Merge Workflow
How to cherry-pick multiple commits
How do you merge selective files with git-merge?
How to cherry pick a range of commits and merge into another branch
ReinH Git Workflow
git workflow for making modifications you’ll never push back to origin
Cherry-pick a merge
Proper Git workflow for combined OS and Private code?
Maintaining Project with Git
Why cant Git merge file changes with a modified parent/master.
Git branching / rebasing good practices
When will "git pull --rebase" get me in to trouble?
