Introduction
Git is one of the most used version control systems by developers. In this article, I am sharing some of the useful recommendations I believe I can provide to others regarding the same.
Recommendations
Write Change Specific Commit Messages
It doesn't matter if your change is spread across a lot of files or is limited to changing the syntax of the function. There is always a thought/aim/problem which you think of while making the change to achieve it. Ensure that your commit message reflects the same so that other developers who view it can understand why you made that change.
I always try to write my commit messages keeping these points in mind:
- What was the reason I decided to make this change?
- Does this change achieves the desired outcome or are more commits required?
- Who tested it and how?
Writing vague and generic commit messages should be avoided as much as possible as later on, in the long run, they for sure create confusion for the developers on what the actual reason was for making the change.
Check out this stackoverflow question on the same topic which is a good read as per me:
Tim Pope argues for a particular Git commit message style in his blog post http://www.tpope.net/node/106.
Here is a quick summary of what he recommends:
- First line is 50 characters or less.
- Then a blank line.
- Remaining text should be wrapped at 72 characters.
His blog post gives the rationale…
With Due Care, Force Push
I have personally seen a lot of developers either hating force push or force pushing on a daily basis. In my opinion, force push is like a knife. If you don't handle it with care you might indeed destroy your work, but it is also something that is really useful to avoid a mess of the same.
I do force pushes on my temporary WIP branches only, to avoid creating multiple trivial commits which are later on deleted (branches) once it gets merged into the main branch. On every project, its main branch is the most important branch which is used by the downstream and other developers to base their work upon. If you are force pushing your project's main branch, ensure a backup exists to avoid issues later on.
Checkout cregox's answer to this question on stackoverflow which I believe is a great tip:
I've set up a remote non-bare "main" repo and cloned it to my computer. I made some local changes, updated my local repository, and pushed the changes back to my remote repo. Things were fine up to that point.
Now, I had to change something in the remote repo. Then…
Utilize Git Subtree/Submodule For Dependencies
A lot of projects sometimes involve some kind of dependency which is usually another project. A lot of developers, as I have seen, import the project into their by manually copy-pasting and removing the project's specific .git directory. This results in loss of commits log, a burden to upstream the project regularly, and whatnot.
In my case, when I need another project as a dependency but has no requirements to modify it to adapt it for my project, I use the git submodule feature, and when I need to adapt the dependency project for my specific needs, I use the git subtree. If you are new to these features, I urge you to check them out as they might save a lot of time for you.
Here is a great stackoverflow question on which the differences between both are explained quite well:
What are the conceptual differences between using git submodule and subtree?
What are the typical scenarios for each?
Sign Your Commits Whenever Possible
Signed commits add a layer of trust and security for the other people who use your work. It ensures that a commit is actually committed by the said person and hasn't been modified by others.
There is also a great Q/A on this StackExchange site I would refer to:
Simply put, I am wondering why would one need to sign one's commits with a GPG key when contributing to GitHub when one's already required to provide an SSH public key?
You can read my dedicated article on this site on how to do it as well:
I confess that I need to follow this recommendation of mine more as I do push a lot of commits without signing them.
Top comments (1)
Gitmoji (gitmoji.dev/) is also an amazing way to describe your commits and help keep them clean and to the point!