Git is an incredible tool if you know how to use it.
In the past, I merely saw Git as a tool to collaborate with others. Using Git usually meant making commits with non-descriptive identifiers like the word 'fix' or a task number pushed directly to the remote branch.
However, Git is so much more than this, and if you are using Git in the same way, you may find this series of articles beneficial.
We'll start by defining some best practices for handling a repository.
When Should I Use a Version Control Tool?
You may answer, "When collaborating with remote colleagues or team."
Correct, but incomplete. Git keeps track of every change and improvement made to your project's codebase. It is a great backup and rollback system, even if you are working alone. So unless you are working on a very small one-page project where all you need to do is deploy and never edit it again, you'll probably find Git helpful from the very beginning of every project, solo or collaborative.
How to Write Meaningful Commit Messages
The first unquestionable rule here is that commits should be written in English, regardless of your native language. Why? For the same reason that programming languages are in English: it's the lingua franca - understandable by everyone. You never know if someday you'll be working with foreign people with a native language different from yours, but consider that you suddenly might have to collaborate with people from 4 different countries, and everyone starts writing commits in their native language. What a Babylon!
This isn't uncommon: what if, someplace down the line, you decide to change your project to open source? There you are: your repository will now potentially be exposed to a worldwide audience. Writing in English from the beginning will make the repository readable for everyone forever, no matter what you initially planned.
Another good practice is to have a specific style in writing commits. This not only makes the repository history cleaner but also makes it very useful. If you have a backlog of issues related to the project, mark the commit messages with their unique identifiers. How is up to you:
[BACKLOG-XXX] <message>
ref. #BACKLOG-XXX <message>
BACKLOG-XXX - <message>
There is no one correct style. What matters is to stay consistent from the beginning.
Another style you may want to use is the conventional commit, which is very good since it also helps to define what type of changes a particular commit contains.
Concerning the message part of the commit, a good practice is to write it as an imperative command that explains what the code should do if the HEAD of the repo were to point to that commit hash. So, for instance, let's say you just finished writing a new component that represents a product card in your project; instead of writing "added a product card", you could write "create a product card". Notice that the verb is imperative. Pointing to a specific commit hash that asks to do something makes more sense if you are moving backward and forward in your git history.
Apart from messages, I suggest grouping file changes regarding a specific function under the same commit message. So if you've, for instance, edited a file to change the page title and also created a new component in the same branch, these two tasks should be split into two different commits with their own specific "command commit message".
In the next episodes, I will give more practical and clear examples of what I mean.
Further on, we will see how to commit only some portions of the work-in-progress files under different semantic commit messages with no headaches. As said, it's useful keeping separate commits for every semantic task for several reasons, two of which are reverting changes and cherry-picking, which we'll also see later on in detail.
Last but least, and perhaps most importantly, commits should always have a message. It's trivial, but it's common to see pushed commits without messages or a default no-message message which is entirely useless.
The commit message should neither be too short nor too verbose. To write a useful message, think about writing a note to your future self about what the committed files do, using searchable keywords. It really helps, especially when you are searching for it for real later on.
So always remember to write your commit messages following the previous tips.
A clean repo, counting informative commits and good use of branches, will become a very powerful and useful tool for your daily work that you will no longer be able to do without.
So, with these first tips in mind, you’re ready to start a wonderful journey in Git and its Flow!
Essential Tools
Before diving into this, I strongly recommend downloading GitKraken, which gives you a visual map of how your repo is managed. I'II illustrate every step through this tool so that it's easier for you to follow and understand. Of course, you can do all the things we'll get into via the command line, but some could be very hard to figure out without a visual schema.
We will also see how Github and Gitlab enable you to do some of the actions we'll dig into directly on the remote repo.
 "GitKraken")
