How do you usually use git? A couple of basic commands to " sync all ." Git frustration often occurs in those who never go beyond this superficial understanding. However, mastering git will certainly pay off. How much time do you spend using git? I would suggest that there are a lot of tools on your belt that you use twice as rare and have spent twice as much time studying.



If you want to learn more about git, I suggest starting with chapter 10 of the Pro Git book (it's free!), Then chapters 2, 3 and 7. The rest is optional. In this article we will discuss how to apply the tools described in the book for disciplined and productive work in git.

Basics: good commit descriptions

')
You may have heard it before, but be patient. As a rule, you do not need to use git commit -m " " . Start by setting up git to use your favorite editor: git config --global core.editor vim , then just run git commit . The editor opens, and you can write your own description of the commit in it. The first line should be limited to 50 characters and complete the sentence: after applying this commit ... "correct text rendering in CJK languages", "add support for v3 protocol", "refactor CRTC processing", etc. Then add one blank line and Go to the extended description of the commit , which must be hard formatted in 72 columns and include such details as the justification for the commit, compromises, limitations of the approach, etc.

We use 72 characters, because this is the standard email width , and email is an important tool for git. The 50 character limit is used because the first line becomes the subject of your email, and you can add a lot of text to the beginning, like “[PATCH linux-usb v2 0/13]” . You may find such formatting restrictions annoying and burdensome, but note that others do not read the logs in the same context as you. I often read the commit logs on a vertical monitor, and it will not squeeze as much text into one line as your 4K 16: 9 display.

Each commit should be a standalone change.

Each commit should contain only one change - avoid small unrelated changes in one commit (in this regard, I could often listen to my own advice). In addition, avoid splitting one change into multiple commits, unless the idea is broken up into separate steps, each of which is a complete change. If there are a few changes in your working tree and you only need to commit some of them, try git add -i or git add -p . In addition, each commit must compile, successfully pass all tests and avoid known bugs that will be fixed in future commits.

Now you can take any commit and expect the code to work correctly. This will come in handy later, for example, in the process of selectively including commits in the release branch. This approach also increases the usefulness of git-bisect ¹ , because if you expect the code to compile and successfully pass tests for each commit, you can pass a git-bisect script that programmatically checks the tree for errors and avoids false positives. These standalone commits with good descriptions will simplify the preparation of release descriptions using git-shortlog , as Linus does with Linux releases .

It's hard to get it right the first time.

We come to one of the most important features of git, which distinguishes it from its predecessors: history editing. All version control systems are shipped with some kind of “time machine”, but previously they were mostly read-only. However, the git time machine is different: you can change the past. In fact, you are even encouraged to do this! But I warn you: change only the past that has not yet entered into a stable public branch.

The essence is as follows. Writing commits without errors, autonomous commits with a good description is difficult on the first attempt. By contrast, editing a story is easy, and this is part of an effective git workflow. Check out git-rebase and use it freely. You can use rebase to reorder, merge, delete, edit and split commits. For example, I usually make some changes to the file, send fixup commits ( git commit -m fixup ), and then use git rebase -i to infuse it into an earlier commit.

Various tips

• Read the mana! Choose a random git man page and read it now. Also, if you didn't read the top-level git man page (just man git ), do it.
  
• At the bottom of each mana for a git high-level command, there is usually a list of low-level git commands that the high-level command relies on. If you want to learn more about how the high-level git command works, try reading these man pages.
  
• Learn how to select commits with rev selection .
  
• The branches are useful, but you have to learn how to work without them, and also have a good set of tools on the belt. Use commands like git pull --rebase , git send-email -1 HEAD~2 and git push origin HEAD~2:master .

1. In a nutshell, git bisect is a tool that performs a binary search between two commits in your history, looking at the commits between them one by one, so that you can check for an error. This way, you can calculate the commit that caused the problem. ↑