Git is a well-known version control system that makes developer teams’ lives much easier. Many developers use it just to be able to share some code and work on it simultaneously but git is far more powerful than this 😉
If you want to learn more about git and how to use it, check out this article.
Today I will concentrate on the commits. So below are some tips and tricks of how to make git commits as helpful as possible.
From Git Commit History To Project History
First of all, you need to be attentive with your commit history. Commit history, if used properly, can be your project history and reflection of all the tasks the developers have done. In the perfect world, a task should be so small to fit in one commit, and, similarly, a commit should be big enough to contain a task. Let’s talk with examples:
Bad commit history 😨
- “Add 1st part of X feature”
- “Add final X feature”
- “Fix a bug on X feature”
- “Another bugfix”
- “Fix small styling issue of X feature”
- “Fix typo in the text”
- “Add comma in the text”
Good commit history 👼
- “Add X feature to dashboard page” (contains all the small fixes and changes)
- “Add Y feature to homepage”
Of course, there are many approaches on how to write a commit message, about which I will talk a little bit below. But the idea here is that in the “bad commit history” example there are 6 small commits about the same feature, and most of the commits are even just 2–3 lines of code or even just 1 letter change. In contrast to that, “good commit history” has only one commit for that specific feature.
NOTE: This is only good if the 1 commit really includes the changes related to X feature. Don’t make unrelated (even small) changes when working on a specific task. Your commit message should exactly describe your changes.
There are a lot of advantages in this style of working, some of them are:
- You can easily remove a change/feature by just removing 1 commit
- Other developers will know which line of code is for which feature (e.g. by using git extensions in their IDE)
- Such commits are more meaningful and helpful
“Talking is easy, how can I know when I am done to make just one commit, I find bugs and mistakes unexpectedly?!?!?!?”. 😝
Hey! Hey! Hey! Don’t get mad and just keep reading. Here is how! 👇
Amending Your Commits
As I already told, it’s perfect when you make just one commit for a task rather than multiple small and sometimes meaningless commits. Let’s imagine you completed the task (at least that’s what you think at that moment), you are very happy and you decided to commit and push your work. You did it. But… OMG! You wrote “We can holp you” instead of “We can help you”. Now you should make another commit that says “Fix a typo…” because you should fix it! Wait, wait, wait! Don’t do that, please. 🙌 Do the following:
git add .
git commit --amend
Magic! This will take your last commit, bring it back, add your new changes and make a new commit! After the command, it will open a window with your last commit message, in case you want to edit it and describe your last changes there. So after confirming it, you will have a new commit that includes all the changes. If you don’t want to change your commit message, then run the following command:
git commit --amend --no-edit
You can now push it and enjoy your clean commit history. 😆
Commit Messages & Authors
I am sure you know the situation when you find a piece of code that seems either really horrible and meaningless or is very difficult to understand what it does. In such situations there are 2 solutions:
- Author should make sure to add explanatory comments to the complex chunks of code
- Author should write good git commit messages
Writing comments is extremely helpful, but you cannot write a comment for each line of code as in that case you will have to write more comments than actual code because “talking language” is always longer that “coding language”.
However, if you use git, every line of code belongs to a commit. Nowadays, most of the IDEs have git extensions that makes it so easy to connect the code with the git history. So you can easily find out the commit message for that code and the author of it. (Let’s pray that you don’t find your name as an author of a terrible commit 🙏). And whether this will be a helpful commit that eases the life of developers OR just a command to push it to a repo, is decided by YOU! So let’s work to make it be the first option.
There are usually some commit message conventions in each company. For example:
- If you are using a task management system, like Trello or JIRA, adding the task number at the beginning of your commit can be helpful. In case of using JIRA, when you add the task code at the beginning, it automatically connects your commit to the task and displays the related commits and actions in the task description, which is a huge benefit.
- Some people prefer using past tense rather than present tense, like “Added new feature”, but I personally prefer writing “Add new feature”. When the task is still in progress, but you are making a commit you can use the verb in the continuous form (with -ing ending), like “Integrating smth”.
- When the project is big, sometimes it’s being divided into smaller parts and each part has its code to visually see which commit contributes to which part of the project. For example, in a project there can be 2 huge sections that are requiring quite different approaches and features — services (SRV) and products (PRD). If you made changes in the services section your commit message will start with “SRV”.
- Another approach is to mention the page name in your commit.
An example of a commit message using these methods will be:
“SRV-34 (Homepage) — Add newly designed loader”
As now we know that each line of code is attached to a commit. That’s why it’s really important to have small and meaningful commits, descriptive commit messages and avoid from making changes that does not relate to the specific task or commit. I know it’s hard to resist the desire to improve a syntax that you just noticed sucks, or fix a typo that belongs to another task and stayed unnoticed. But such changes add confusion and difficulties for the reviewer and fellow developers. It’s best to note all of these changes you want to make, and do that later with another refactoring commit.
This is what I have prepared for the first part, but there is still a lot to share about git superpowers. So stay tuned and share your thoughts below! 😊