Published 18/07/2020 at 06:32pm

Being A Nice Git User

I'm writing this article to explain why it is important to be conscientious git user. Having encountered bad practices and having to deal with the consequences throughout my career I thought I'd share a few simple tips and thoughts to make things better. I hope it helps out you and your team.

What does a "nice" git user mean?

  • Commits are atomic - a set of distinct changes, they can stand alone so you could apply it or revert it and the other commits would be unaffected or have meaning by themselves.
  • Commit messages explain why you did something rather than what you did - your code will do that for you
  • Always thinking about other people you work with; their roles and responsibilites, knowing that somebody will always be code reviewing it (even future you) so do them a favour and make it as easy as possible

How can I be "nice"?

Other than following the best practices above, pratically you can use -p flag which is the patch flag and allows you to interactively choose which lines of code you want to add or commit:

git add|commit -p

Note: you can pretty much use any git command with the -p flag where you need to be selective.

If you choose the right stuff here then it makes it really easy for you to make commits atomic and gradually build the work you've done better showing the story of development. This gives code reviewers and future maintainers a much clearer picture of what that code is doing and why we're doing it, making it easier to maintain and giving much betrter context when bug reports come in.


Lots of flexibility - At the time you don't know whether particular commit(s) will need to be fast tracked in to the main branch or whether another team or another branch will need something your working on. If you've structured commits well than you give yourself the flexibility to do whatever you need to and not waiting for work to be merged to the main branch if needed.

Easier to review - It is so much easier to review if commit messages say why you've done something. If something doesn't look right in a review then having decent commit messages can perhaps highlight why something was done a particular way. Show respect to colleagues. As the saying goes, treat others the way you'd like to be treated and the same goes here. Make code review as easy as possible for them.

Understanding intent - Probably the one that causes the most issues. A lot of problems occur in software development where you don't know or understand intent. You could potentially change a piece of code and cause unexpected issues, particularly in legacy systems. Knowing why something was done in a particular way could go along way to stopping you from changing a piece of code or changing your approach to fixing the issue.

Easier to debug in smaller increments - Whether the issue has been spotted once live or whilst in development a common method for debugging is git bisect. If your commits are small then on finding the offending commit it is much easier to fix the issue checking 3 lines in one file rather than 300 lines across a directory.

Code is more up to date - Because commits are smaller it can encourage you to push more frequently meaning other members of your team are inherently working on up to date code more readily and easily.


If you follow these better practices it won't stop problems from occurring but you will make things much easier and will speed up development. Although indirect, it will likely increase respect amongst team members.

Thanks for reading.

© Louis Rickman 2021