33

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?

gnat
  • 21,442
  • 29
  • 112
  • 288
Makoto
  • 837
  • 1
  • 8
  • 14
  • 1
    The "Rule 3" section from [Ted Dziuba's old blogpost](http://widgetsandshit.com/teddziuba/2011/12/process.html) might help illustrate how it can be an anti-pattern. – Isxek Feb 19 '13 at 05:08
  • 5
    IMO, the more actual time you're spending thinking about version control, the more that's gone wrong with the whole user -> tool phenomenon in the first place. – Erik Reppen Feb 19 '13 at 06:06
  • @ErikReppen: I'd like to take everyone's minds away from version control and have a process that everyone can get used to. This way, we don't have to worry about things like if this is an anti-pattern or not. – Makoto Feb 19 '13 at 06:09
  • 6
    @Makoto Anything that violates KISS is an anti-pattern, IMO. This is where VCS power users tend to make me crazy. – Erik Reppen Feb 19 '13 at 15:50
  • 6
    The term "antipattern" is kind of like "best practice", in that it often serves as an excuse for people to turn their brains off. Don't accept this notion if the lead can't tell you clearly what experience he has with it and why it's bad. – Kyralessa Feb 19 '13 at 21:02
  • "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" I'm not sure why you think Gitflow would be a solution to this problem. It *prescribes* that you merge changes back and forth like this, often merging the same changes into multiple branches or even having to create and merge commits that don't actually contain changes to any file in the repository. – jpmc26 Jan 12 '16 at 00:24

3 Answers3

31

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 3
    My experience with feature branches, or the way we've done them, is that there can be heartache with them if they're allowed to live for more than an iteration. A rule that states that all features must be merged into the iteration before release would be nice, to alleviate the heartache of merges - and boy, have we had some serious heartache behind those... – Makoto Feb 19 '13 at 06:05
  • 6
    My experience is that you can have local stuff lying around for long as long as you keep it merged with recent master and or develop as appropriate. – Jan Hudec Feb 19 '13 at 10:25
  • 2
    @JaHudec ... or until you have two things lying around which are conflicting in some way. You should always have the overview about that being done... – johannes Feb 19 '13 at 23:01
  • 5
    Doing a bit of reading up on it, and [Martin Fowler's reference](http://martinfowler.com/bliki/FeatureBranch.html) seems to indicate that feature branches done in a continuous integration flow can work out - if they're done in smaller bites than what most people would consider doing them for. So, in a sense, you're right - less than two weeks as a time-to-live on a feature branch seems suitable. I don't see, however, how feature branches themselves are the anti-pattern. – Makoto Feb 20 '13 at 01:36
  • 3
    You're right. They are only an anti-pattern when they live too long without being merged. Sometimes people still rail against an idea when they don't remember the underlying reasons. – Karl Bielefeldt Feb 20 '13 at 02:35
  • Feature branches are not inherently bad. I've had both success and failure with them. I've experienced major headaches and seen it fail on a project that (imho) suffered from poorly organised code, unclear/ever-changing requirements, bureaucracy, and lack of manpower in teams we depended on (resulting in some feature branches staying open for *months*). – Stijn Aug 24 '17 at 13:23
  • Feature branches can be a challenge but if you have a scenario where you don't know which features will be released together, it can really help. – JimmyJames May 02 '23 at 19:46
23

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.

maxim1000
  • 745
  • 4
  • 8
  • 1
    Nah, not using branches is a non-starter. The other primary issue would be that work can be done in two different places in the same code, so hopefully we can do something to alleviate that, too. – Makoto Feb 19 '13 at 06:06
  • 13
    @makoto, quite often decoupling things in code makes conflicts less frequent. It can be either plain separation of a functionality into functions/classes or more high-level avoiding of undocumented assumptions between modules. Then changes become more localized. – maxim1000 Feb 19 '13 at 08:21
  • 2
    @maxim1000 I agree. I think someone once said something like "A VCS is a poor man's alternative to modular [decoupled] architecture" – 8DH Oct 22 '13 at 08:02
1

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 develop into master are trivial true merges—so trivial that they could be fast-forwards
  • Merging master into develop after a release should only give simple conflicts like version string metadata conflicts
  • Merging master into develop after 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
Guildenstern
  • 249
  • 1
  • 6