My company is using Git, and is using a peculiar branching scheme – work is done in master, and branches are reserved for releases. This works fine, so long as all of the work done in an iteration makes it into the branch, but if a critical production issue comes up, we have to ensure that the work somehow makes it into both branches.
Lately, we’ve been having some “fun” with those branches. It’s been an administrative headache, ensuring that all of the work makes it into every branch, and some bugs which have been fixed on one branch don’t make it into master until someone points it out, which is concerning.
I came across Git Flow a while back, and I feel that it would be a solution to our problem – code not percolating all the way to the release, or all the way back down. The only catch is that my lead stated that this sort of development was an anti-pattern – developing furiously for two weeks, then spending three to resolve the merge conflicts.
I’m not entirely sure I agree, and since I brought it up, work has resumed like normal. Only recently have we had some major pain points with this.
I’d like to know – why would this sort of development scheme be seen as an anti-pattern? Is it really an anti-pattern?
6
He’s mostly referring to the feature branches side of the model. Feature branches were declared an anti-pattern a long time ago when the branches lasted for months and version control systems couldn’t merge to save their life. Feature branches that last a week or two have much fewer issues, especially if you’re continually merging from develop into the feature branch during that time. Anything much longer than that is still not recommended.
Even if you don’t use the feature branch side of git flow, the other parts are useful in ensuring you get clean merges and your changes are propagated in the right direction.
7
Merging is a funny thing – the less frequently it’s done the harder it will be, the harder it is, the more people will be afraid of it, the less frequently they will do it.
Solution is either do not allow branches to deviate too much, or not to use branches.
If people understand this, you will probably have not much problems with merge, if not – may be branches are not a good idea without some education.
3
The only catch is that my lead stated that this sort of development
was an anti-pattern – developing furiously for two weeks, then
spending three to resolve the merge conflicts.
Git Flow shouldn’t have this problem to any larger degree than any other
Git workflow.
The core daily development workflow common to most Git workflows—whether
they involve pull requests or patch series sent out via email—is that
you have feature/topic branches that are based on the development branch
(perhaps named master/main/develop). And this is where all of the
nasty merge conflicts happen, i.e. conflicts between feature branches.
As a developer you deal with that by:
- Rebasing or merging in things often until your changes get accepted
(don’t wait until the end)
As a team you deal with that by:
- Making sure that people don’t work on the same code in paralell
- Try to avoid weeks- or months-long feature branches
And Git Flow is exactly like other Git workflows on this point.
Git Flow is different from other workflows in all that “production”
stuff; merging develop into master, branching hotfix off of
develop and then merging that into master and develop…
But this isn’t where your merge conflicts should happen:
- Merging
developintomasterare trivial true merges—so trivial
that they could be fast-forwards - Merging
masterintodevelopafter a release should only give
simple conflicts like version string metadata conflicts - Merging
masterintodevelopafter a hotfix shouldn’t give many
conflicts unless you were so uncoordinated that you developed some new
feature “on top of” the area that you were fixing