About Git Beginners and Git Starter Articles

Friday is the thirteenth great day for the next holywar discussion of "how I prepare Git, and why I prepare it wrong."
So, Every programmer, whether under Linux, or under Windows, will always find someone who rotates, respectively, in the circles of programmers under Windows or Linux. So I have programmers from the world of Microsoft and Windows. It is commendable that such people are starting to move towards OpenSource and Git. But now is not about that.

In the story, I will sometimes rely on the famous Pro Git book written by Scott Chacon.

Case 1: What's wrong with git commit -m ?

')
In one of the conversations on the Internet, an article was mentioned for those who started Git, namely this one . Also, someone suggested that the articles “how I prepare Git” contain nuances that it is difficult to get rid of later, like a bad habit. I'm still not lazy and read the article. And I dare to agree with the above opinion.

In order, what is offered in the article besides a lot of useful tips ? In particular, such moments:

1. git commit -m "Commit message"
2. git reset --hard as a means of interrupting a failed git merge
3. some kind of complex representation of git rebase bar , but we will not talk about this

Why do I think these tips are not very good, which can turn into bad habits over time?

Firstly, git commit -m "Commit message" undoubtedly useful for wip (work in progress) changes (the concept is well traced when using git stash ), but harmful for real changes in public brunches, as they often try to describe everything in one line . As a rule, only the first line of the message, which is often limited to 50-60 characters (and in many cases only the first line is visible to the user, such as git log --oneline ), can the essence of the change be understood. If a more detailed description is needed, add it by skipping one line after the single line.

Here is an example of how changes are made:

 Summary: short, usually up to 66 characters, an explanation of what makes this change
 <blank line>
 Description: detailed,
 possibly multiline
 an explanation of what exactly makes a change, with error logs, etc.
 <blank line>
 Tags: optional tags, type
 Signed-off-by: First Last <cool@email.com>
 Reviewed-by: First Last <cool@email.com>

As an example, open any project on GitHub, in which comments are made in the style of git commit -m , in one line. This line breaks and carries into the body of the message, which implies a detailed description. The same applies to other utilities for displaying repositories on the web.

Secondly, many Git command line commands have the --abort option. In this case, git reset --hard , although the result is correct, is tantamount to shooting sparrows.
git reset --hard cleans the unstaged and staged databases, walks through the entire repository and restores files from the index if they have been modified, then resets the pointer to the specified ID.
git merge --abort comes easier because he knows what has changed, where it has changed, and where it should return.

Case 2: how to rebase on an outdated feature-branch?

What else I noticed, already in the conversation that I mentioned at the beginning of the article. This is a process that people use, and it is this sequence of actions:

 # rebase myFeature  origin/master # (,   master   ) git checkout master git pull #   git rebase    git rebase origin/master myFeature #      git checkout master git merge --no-ff myFeature # ,     

Now compare with:

 git remote update git rebase --onto origin/master <our old origin> #     git push myFeature:master # ,  master   

Or:

 git remote update origin git merge origin/master #     git push myFeature:master # ,  master   

In the first case, you need to have a local copy of master in the working tree, switching - checkout is an expensive operation, since you need to work with the file system, have you already submitted a repository for a couple of tens of thousands of files, in which, let's say, something has recently been changed from a template?

The second method allows you to update the index, and you can immediately for all remote, then in one operation update the feature-branch, and the third fill in the master or somewhere else. In the first method, this was not the case except for the actual master update.

Case 3: when is it appropriate to --squash ?

Further, some development teams use merge --squash order, as stated, not to clutter the general history with personal changes. But sorry, if it goes to the public (Open Source!), Then all the changes are common, no personal picking in the nose. squash like fixup is only useful when preparing a series of changes to send.

Thus, it is proposed to first make some changes locally, deal with them, arrange in a normal series and pour further, considering that this is all already in public. On the other hand, even if it is an internal repository, it will be difficult to find the ends of a problem. Apparently not many people imagine what is really happening in production.

Bonus

And as a bonus, such a command (note the option --list ):

 git branch -a --list myremote* 

Estimate the usefulness yourself, in particular, if you put the Linux kernel and several subsystems at once into one tree, somehow: linux-pm, linux-tty, ...

Yes, and Google will close Google Code.