All of those cases below are not made up. I’ve met with those cases -> sometimes as ideas, sometimes they were even used in practice. But they all have one common feature - they should be avoided at all cost. To simplify things, I’ve used Git Flow naming convention, as it’s pretty versatile (http://nvie.com/posts/a-successful-git-branching-model/).

What has inspired me to write about that just right now? I’ve spend some time on explaining the trouble related to those scenarios recently, so I’d prefer to have it written next time already :)

  1. Parallel develop branches (living longer than feature branches)

    You seriously do *not* want to merge two actively developed branches for longer than few days, It takes time, it doubles the testing at least for one the branches and it requires a strictly set work discipline. It gets even worse when there’s a problem with precisely determining which of the branches will get released first (because you can’t determine the merging direction!). Children, don’t do that at home: release often, release small chunks, decouple products (and release them separately).

  2. Long-living feature branches

    Feature branch destiny is to live shortly. Usually it’s local only and it doesn’t have a dedicated test environment (so it’s not in CI) -> that kinda kills one of the most important rules for professional software development: integrate as early as possible. IMHO  local feature branches should never live more than 1 week.

  3. One merge before the release

    Never, ever postpone merging. Merge as frequently as possible. And test both branches (branch being merged before merging and the branch you merge onto during the merge). Regardless of tech you use, refactoring happens and tools like ReSharper may change a lot (I’m not questioning the added value of refactoring) -> if some of such changes combine, it may cause you hair go grey.

  4. Out-sourcing the responsibility for merging

    People who merge the code should: know this code, be the ones who are responsible for the code. Don’t ask your Ops to do the merging for you - merging is not a purely “mechanical” duty (when conflicts happen …): sometimes it requires very conscious adjustments -> Ops are not to take the responsibility for the content of the source code.

  5. If you’re planning to release from one branch …

    … but you know that some of the functionality won’t be activated (because it’s supposed to get released later - things are not entirely complete, etc.) -> make sure that your developers are aware of that since the beginning, so they can shape the code in a proper way (so they don’t have to “decorate” the code with zillion of IF statements in the end).

Any anti-patterns from hell you’d like to share?

Share this post