This is my take on Gitiquette.
Software developemt equals tradeoffs. Git usage is one of them. Sometimes it’s better to structure your commits ( and code ) in a way that’s more sociable to other developers. This concept can take a little while to sink in when you’re starting out and indeed it did for me. Sometimes a little bit of structure can make all the difference.
Small teams vs big teams
When you’re working in a small team there is often much less need for Gitiquette. However it is not completely irrelevant.
A good habit to get into is using topic branches.
Never force push production!
git push -f origin production
This is possibly the worst thing you could do! Other developers will either see this as very stupid or very questionable. In most cases though, integration branches are protected and if they’re not, you should ask why.
The reasons for this are:
1) You could be attempting to hide a change in the history ( potentially introducing a vulnerability or covering up a previous bug ). 2) You could be overwriting someone elses changes without realising it.
ALWAYS do a
pull first and then
push when the remote can be fast forwarded.
Format your commit messages
There is a good article on this subject from 2008 by tim pope.
Write meaningful commit messages
Try to think about the next person who will be reading through your changes deown the line.
Squash your topic branch before merging.
It’s the WORST thing when you see someone merge changes into production and they’re a long bunch of commits with pointless titles like:
add the var
remove the var
add the var again
GO AWAY filter
meh ... no var assigned
If you’re working on a feature that has lots of complex changes there is a good chance you could break it down and make commits that are less daunting for another developer to read or understand.
commit 1: migrations for change commit 2: add backend code that will use aforementioned migrations commit 3: add frontend code that will make the feature usable
Before blinding merging your changes to production does it really hurt to let another developer take a brief look?
Be discerning about this.