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

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

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

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

4. WIP

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

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.