How is git usually used? A pair of basic commands to " synchronize everyone ." Git frustration often arises among those who never go beyond this superficial understanding. However, mastering git will surely pay off. How much time do you spend using git? I would suggest that on your belt there are a lot of tools that you use half as often and spend twice as much time studying.

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

The basics: good commit descriptions

You may have heard this before, but be patient. Generally no need to use git commit -m "ваше сообщение здесь". Start by setting up git to use your favorite editor: git config --global core.editor vimthen just run it git commit. The editor will open, and you can write your description of the commit in it. The first line should be limited to 50 characters and completed with a sentence: after applying this commit ... "will fix the text rendering in CJK languages", "will add support for the v3 protocol", "will refactor CRTC processing", etc. Then add one empty line and go on to the extended description of the commit , which should be hard-coded into 72 columns and include details such as justification of the commit, trade-offs, approach restrictions, etc.

We use 72 characters because itThe standard width of an email message , and email is an important tool for git. A 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 these formatting restrictions annoying and burdensome, but keep in mind that others read the logs in a different context than you. I often read commit logs on a vertical monitor, and it won’t squeeze as much text into one line as your 4K 16: 9 display.

Each commit should be an autonomous change

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

Now you can take any commit and expect that the code will work correctly. This will come in handy later, for example, during the selective inclusion of commits in the release branch. This approach also enhances the usefulness of git-bisect ¹, because if you expect the code to compile and pass the tests for each commit successfully, then you can pass a git-bisectscript that programmatically checks the tree for errors and will avoid false positives. These stand-alone, well-descripted commits will simplify the preparation of release descriptions using git-shortlog , as Linux does with Linux releases .

It’s hard to do it right the first time

We come to one of git's most important features, which sets it apart from its predecessors: story editing. All version control systems come with some kind of "time machine", but before 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: only change the past, which has not yet entered a stable public branch.

The bottom line is as follows. Writing commits without errors, autonomous commits with a good description is difficult on the first try. Editing a story, by contrast, is easy, and it is part of the git efficient workflow. Check out git-rebaseand 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, submit the fixup commit ( git commit -m fixup), and then use git rebase -iit to inject it into the earlier commit.

Various tips

• Read mana! Select a random git man page and read it now. Also, if you have not read the top-level git man page (simply man git), do it.
  
• At the bottom of each mana for a high-level git command 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 the right commits with rev selection .
  
• Branches are useful, but you must learn to work without them, and also have a good set of tools on your belt. Use commands like git pull --rebase, git send-email -1 HEAD~2and 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 at a time so you can check for an error. In this way, you can calculate the commit that caused the problem. ↑