Every day, we constantly code and fix bugs along with other team members. Suddenly, one fine day, the tester screams about an error that you had fixed weeks ago. You immediately speak up, stating that you had already fixed it and you need to prove it to the tester. You open the commit history and boom... commit, fix bug, fix some bug... are the things that hit your eyes. And guess what? Those are the commit messages you made!
Now, how do you find that specific commit? You torture yourself wondering why you didn't commit more clearly at that time. Don't worry, everyone makes mistakes, and mistakes are meant to be fixed. But what's more important is that you have to recognize that you made a mistake and share your method of improvement!
That's right, first and foremost, try to come up with clear messages that are action-oriented towards the target.
For example:
I'm using Vietnamese as an example, but depending on the project's rules, you can also commit in English, but the essence and content should remain the same.
This is a method that many developers have applied in various projects on the social network platform Github. By using prefixes to categorize your common commit types in the project, you can easily differentiate and search for them.
In general, there will be some prefixes that developers self-agree upon, but it's not necessary to follow them.
Some commonly used prefixes are:
There are many other prefixes as well, which you can refer to in this article How to Write Better Git Commit Messages – A Step-By-Step Guide.
For example:
I understand that many of you (including me) often encounter situations where while working on one feature or fixing a specific bug, we suddenly discover another issue and fix it conveniently. Then, when it comes to commit, we only write a generic message like "fix some bugs". This may be convenient, but it complicates tracking. Therefore, try to fix them one by one in a clear manner. Don't be afraid of using multiple commits and commit clearly.
Git flow is a term that refers to the "conventions" followed by a team in a project. For example, a project might have 3 branches: master to store the latest code, release to determine the production-ready features, and develop to develop features for release.
In addition, Git Flow also defines the branching and merging flow while developing features. There is a well-known Git Flow called Git-Flow Cheatsheet which developers can refer to.
If you are comfortable with the command-line interface, that's okay. But personally, there have been many times when I had to use tools for managing Git. I find it convenient and it helps me keep track of the project's flow.
Nowadays, almost all code editors integrate or have plugins that allow easy and convenient Git management. Developers can explore further based on the specific tools they are using.
The above sharing is based on my experience, and it is up to the developers to apply them depending on their team's work and project flow. If you find them not suitable or have better suggestions, please leave a comment and let me and others know!
5 profound lessons
Every product comes with stories. The success of others is an inspiration for many to follow. 5 lessons learned have changed me forever. How about you? Click now!
Subscribe to receive new article notifications
Comments (2)