I’m not sure whether the title describes it best, but lately I have seen a severe lack of best practices when it comes to coding or generally dealing with processes at work.

For example, there’s git-flow. We don’t use it 100%, but our process is close, outside a few quirks, we have a develop branch, a QA branch and a release branch, and things get merged around to some extend. I say to some extend because this week we ran into a major issue where fixes were made on a specific branch and not merged down to the others.

This of course resulted in major merge conflicts, without a clear overview of what is the correct solution. Add to that, that we had broken code in the develop branch, it took pretty much the whole day to simply resolve the merge conflict, delaying our release plan by more than a week already.

A major problem that surfaced is a lack of overview. People often have branches with over 20 commits. Which is good, because it means they follow the “commit often, commit early” mantra when it comes to git, allowing minor increments and a clear overview when working on a feature. However when you merge this into a project branch with 20 people working on it, it can get messy really fast due the length of commits in the history.

To combat these problems, I’m currently revoking rights on certain branches and slowly educating people, all be it in a harsh way, on how to use git properly and what should be done when dealing with commits in such a large project:

  • Commit often, commit early: As long as you’re on your branch, commit every little thing. This is a best-practice from GIT that helps in keeping a clear overview of your work history.
  • Squash your commits on merge: This reduces your entire branch to a single commit, making it easier to pinpoint it in the history or even revert. Most platforms allow you to do this on merge, or there’s a simple command sequence for it*
  • Merge your changes down! When using approaches like git-flow, when you fix something on a higher-level branch such as release, then merge these changes down to your develop branch. This will prevent merge conflicts on release day and make sure fixes are spread around in time.
  • ASK! If things are unclear on where something should be fixed or merged, always ask your team to raise awareness. This often indicates that tickets or processes are not clear enough or well understood.

Squashing commits

Squashing commits can be done in 3 ways:

# Option 1
git rebase -i HEAD~[NUMBER OF COMMITS]

# Option 2
git rebase -i [SHA]

# Option 3
git reset --soft HEAD~[NUMBER OF COMMITS]
git commit -m "new message"
git push -f