Tag: git

The evolution goes on.  Now that we’ve kind of sorted out most of our infrastructure, development tools, flows and processes, I guess, it’s time to look deeper into the things we’ve had for a while and reiterate over them.

Recently, I’m seeing a lot of blog posts on articles on how to write good commit messages.  Sure, we’ve had these for a while.  But lately things get a little bit more serious.

Here’s one (in Russian) that I’ve read recently.  Here’s another one (in English) that shares some of the concepts and suggestions.

What are they saying?  Well, “write better commit messages”, obviously.  But there are a couple of specific bits which I found interesting.  They are:

• Conventional Commits – a specification for adding human and machine readable meaning to commit messages.
• Commitizen (git cz) – a tool that help to write conventional commits.

For the skeptics among you, I slightly share your feeling.  It does seem like a bit too much overhead.  But as someone who works with an ever-growing team on a large number of projects, I think there is a place for it.  It’ll take a while to integrate, update the process, and enforce the discipline, but I think it’s well worth it.  At the very least, it deserves a try.

There’s a lot of confusion between git merge and git rebase even among seasoned users of git.  “An Introduction to Git Merge and Git Rebase: What They Do and When to Use Them” is a great article explaining the pros and cons of each, and when and why using each of this is better.

While I understand it a lot better now, I still much prefer the merge approach.  It’s simpler and less dangerous, and maintains the full history.  This might get noisy at times, but works as a last resort when trying to understand what was going through the developer’s head when he was working on a piece of code.