How to Mangle your git History

Wondering how you can increase your job security? Here are a few handy ways that you can make it difficult for your co-workers to read through your git history. You might also cause issues for your future self, but who cares.

1. Make your commit message the ticket number and nothing else

Screenshot of commit message that reads “DFH-8899”

This is a great way to make your co-workers use JIRA more - which I’m sure they love doing anyway.

2. Name your commit message after a git operation

Screenshot of commit message that reads “resolved git conflicts” Screenshot of commit message that reads “merge in main branch”

Seeing this message in the main branch is usually indicative that something went terribly wrong while having fun in git. But it’s sure to be useless to future historians.

3. Expletives and exasperation

Screenshot of commit message that reads “f*ck this” Screenshot of commit message that reads “how...” Screenshot of commit message that reads “fix tests... I hope”

This isn’t as entertaining at you might think while trying to debug a production issue.

4. WIP

Screenshot of several commit messages that all read “wip” or “fix”

Make WIP commits to your heart’s content in your feature branch, but they’re not the most readable messages if they end up in the main branch.

5. Combine multiple pieces of work into one release commit

Screenshot of several commit messages that read “May 4th Release”, “June 2nd Release”, and “March 2nd Release”

Batching together many items into one release commit is a good way to make it hard for developers to debug issues or gain historical context.

Conclusion

Most of these things are not a big deal inside a feature branch, but it’s when they end up in the main branch that other people have to read them.

squash merging or interactive rebases are good ways to improve these messages so they aren’t immortalized in history.

Written By Ben Lorantfy

Ben is an award-winning software developer specializing in frontend development. He builds delightful user experiences that are fast, accessible, responsive, and maintainable and helps others to do the same. He lives with his partner and dog in Kitchener, Ontario.More About Ben »Follow @benlorantfy on twitter »