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 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:
    1. git commit -m "Commit message"
    2. git reset --hard as a means of interrupting an unsuccessful git merge
    3. 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 Last 
    Reviewed-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

    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 --hardcleans 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 --abortIt’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.

    Case 2: how to do rebaseon 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 успел поменятся

    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 - checkoutis 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 --squashorder 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. squashas fixupuseful 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.


    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.

    Also popular now: