The importance of commit messages

As discussed in the article on semantic commits , if commit messages do not correctly express what was done (and, if possible, why it was done). The analysis and understanding of the history of system changes are compromised, impacting the speed and even the quality of deliveries. What would be a simple reading of the commit message, to identify and understand a change made in the past, ends up turning into hours of hard work performing diffs (command that compares the content between commits) and code archeology. Even more so if the programmer responsible for the change is no longer on the team or is inaccessible at the time of review. Also, this can get in the way of integrity and reliability in your codebase, because if there is a habit of writing counter-intuitive messages, over time we lose confidence in trying to find the desired versions through commit messages and go straight to the "trial and error". This also impacts the team's speed and productivity, and can generate an "anti-pattern", harmfully influencing the team to write commits in this way ("if everyone is writing generic messages, why should I bother writing something semantic?"). However, imagine a situation where a person is urgently solving a very serious bug in production. Due to this urgency, he didn't really think about the message inserted at the moment of the commit and it wasn't as clear as he could because he was prioritizing the impact on the client. For these and any other situations where it is necessary to rewrite the message (which yes, they happen on a daily basis and that's ok), we can use the commands git commit --amend or interactive git rebase depending on the context.

Using the - amend parameter in commits

If it is necessary to rewrite the message of the last commit made, you can use the commands below:
1) 1git commit --amend -m "feat: add car search by license plate"
2) 1git push --force-with-lease origin master
These instructions will re-push the last commit with the adjusted message. In the example, the message has been replaced with "feat: add car search by license plate" . It is strongly recommended to push with the --force-with-lease parameter , as if someone has added a change that is in front of the commit you are rewriting, the push is aborted. With this, the change ahead is not lost (if you are the only maintainer of the repository, or you are sure that there are no changes ahead of yours, you can use the --force parameter ). Remembering that the origin and master parameters correspond respectively to the name of the source repository and destination branch, and may vary according to the working repositories you are using.

Conclusion: With Great Power Comes Great Responsibilities

As discussed throughout the article, exploited features are very powerful and we are rewriting history, which implies abandoning old commits and replacing them with new ones. In addition, we can still "kill" changes from colleagues if we don't push correctly or if we are inefficient in communications, which can cause more inconvenience than solutions. Therefore, it is very important to be aware of when to use each resource and always ensure the "good neighbor policy" and "etiquette" of use, for the sake of the integrity of the codebase and to facilitate (never disturb) the team's day to day.