About Git, Beginners, and Git Articles for Beginners
Friday is the thirteenth excellent day for another holywar discussion on "how I cook Git and why I cook it incorrectly."
So, every programmer, whether under Linux, whether under Windows, there will always be someone who rotates accordingly in the circles of programmers for Windows or Linux. So I have programmers from the world of Microsoft and Windows. It is commendable that such people begin to move toward OpenSource and Git. But now is not about that.
In the story, I sometimes rely on the famous book Pro Git , written by Scott Chacon (Scott Chacon).
Case 1: what is bad
In one of the conversations on the Internet, an article for beginners in Git was mentioned, namely this one . Someone also suggested that the articles “How I Prepare Git” contain nuances that are difficult to get rid of later as a bad habit. Still, I was not too lazy and read the article. And I dare to agree with the opinion given.
In order, what is proposed in the article besides a lot of useful tips ? In particular, such moments:
Why do I find these tips not very good, which can turn into bad habits over time?
Firstly, it is
Here is an example template of how changes are processed:
As an example, open any project on GitHub, in which comments are made in style
Secondly, many Git command line commands have an option
Case 2: how to do
What else have I noticed, already in the conversation that I mentioned at the beginning of the article. This is the process that people use, namely this sequence of actions:
Now compare with:
Or:
In the first case, you need to have a local copy of master in the working tree, switching -
The second method allows you to update the index, and you can immediately for all remote, then update feature-branch in one operation, and upload the third to master or where else. The first method did not have this, except for the actual update of master.
Case 3: in which cases is appropriate
Further, some development teams use in
Thus, it is proposed at first to make changes locally for yourself, deal with them, arrange them in a normal series and fill in further, considering that this is all already in public. On the other hand, even if it is an internal repository, finding the ends of some kind of problem will be oh how difficult. Apparently not many people imagine what is really happening in the workplace.
And as a bonus, such a command (pay attention to the option
Usefulness yourself, in particular, if you put Linux kernel and several subsystems in one tree at once, such as: linux-pm, linux-tty, ...
Yes, and Google will close Google Code.
So, every programmer, whether under Linux, whether under Windows, there will always be someone who rotates accordingly in the circles of programmers for Windows or Linux. So I have programmers from the world of Microsoft and Windows. It is commendable that such people begin to move toward OpenSource and Git. But now is not about that.
In the story, I sometimes rely on the famous book Pro Git , written by Scott Chacon (Scott Chacon).
Case 1: what is bad git commit -m
?
In one of the conversations on the Internet, an article for beginners in Git was mentioned, namely this one . Someone also suggested that the articles “How I Prepare Git” contain nuances that are difficult to get rid of later as a bad habit. Still, I was not too lazy and read the article. And I dare to agree with the opinion given.
In order, what is proposed in the article besides a lot of useful tips ? In particular, such moments:
git commit -m "Commit message"
git reset --hard
as a means of interrupting an unsuccessfulgit merge
- some complicated idea
git rebase bar
, but we won’t talk about it
Why do I find these tips not very good, which can turn into bad habits over time?
Firstly, it is
git commit -m "Commit message"
undoubtedly useful for wip (work in progress) changes (the concept is well traced when usedgit stash
), but it is harmful for real changes to public brunches, as they often try to describe everything in one line. As a rule, only on the first line of the message, which is often limited to 50-60 characters (and in many cases the user can see only the first line, somehow git log --oneline
), you can understand the essence of the change. If you need a more detailed description, add it by skipping one line after a single line. Here is an example template of how changes are processed:
Summary: a short, usually up to 66 characters, explanation of what this change does <empty line> Description: verbose, possibly multi-line An explanation of what the change is doing, with error logs, etc. <empty line> Tags: optional tags, type Signed-off-by: First LastReviewed-by: First Last
And here is the corresponding excerpt from the book
In general, it's very important to write a good commit message. For open source projects, it's generally a rule to write your message more or less in this format:
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); some git tools can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet,
preceded by a single space, with blank lines in
between, but conventions vary here
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); some git tools can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet,
preceded by a single space, with blank lines in
between, but conventions vary here
As an example, open any project on GitHub, in which comments are made in style
git commit -m
, in one line. This line breaks and carries into the body of the message, which implies just a detailed description. The same goes for other repository mapping utilities on the web. Secondly, many Git command line commands have an option
--abort
. To use in this case git reset --hard
, although the result is correct, is equivalent to shooting at sparrows. git reset --hard
cleans unstaged and staged databases, goes all over the repository and restores files from the index if they were changed, then resets the pointer to the specified ID. git merge --abort
It’s easier, because he knows what has changed, where it has changed and where it needs to return.Turn to the book
The git merge --abort option tries to revert back to your state before you ran the merge. The only cases where it may not be able to do this perfectly would be if you had unstashed, uncommitted changes in your working directory when you ran it, otherwise it should work fine.
If for some reason you find yourself in a horrible state and just want to start over, you can also run git reset --hard HEAD or wherever you want to get back to. Remember again that this will blow away your working directory, so make sure you don't want any changes there.
If for some reason you find yourself in a horrible state and just want to start over, you can also run git reset --hard HEAD or wherever you want to get back to. Remember again that this will blow away your working directory, so make sure you don't want any changes there.
Case 2: how to do rebase
on an obsolete feature-branch?
What else have I noticed, already in the conversation that I mentioned at the beginning of the article. This is the process that people use, namely 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
# решаем конфликтыи и тестируем
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 presented a repository for a couple of tens of thousands of files, in which, say, a template has been changed recently? The second method allows you to update the index, and you can immediately for all remote, then update feature-branch in one operation, and upload the third to master or where else. The first method did not have this, except for the actual update of master.
Case 3: in which cases is appropriate --squash
?
Further, some development teams use in
merge --squash
order not to clutter the overall story with personal changes. But I'm sorry, if this goes to the public (Open Source!), Then all the changes are common, no personal picking in the nose. squash
as fixup
useful only when preparing a series of changes for the parcel. Thus, it is proposed at first to make changes locally for yourself, deal with them, arrange them in a normal series and fill in further, considering that this is all already in public. On the other hand, even if it is an internal repository, finding the ends of some kind of problem will be oh how difficult. Apparently not many people imagine what is really happening in the workplace.
Bonus
And as a bonus, such a command (pay attention to the option
--list
):git branch -a --list myremote*
Usefulness yourself, in particular, if you put Linux kernel and several subsystems in one tree at once, such as: linux-pm, linux-tty, ...
Yes, and Google will close Google Code.