Experience with Git

Do not use git pull to replace it with git fetch and git merge.

The problem with git pull is that it hides the details of the process so that you don't have to understand the different types of branches in git and how to use them. Of course, most of the time this is fine, but once the code has a problem, it's hard to find the wrong place. It looks like the use of Git pull will surprise you, and simply look at Git's usage documentation to convince you.

Another drawback to putting the download (fetch) and merge (merge) into one command is that your local working directory will be updated by the remote branch without confirmation. Of course, unless you turn off all security options, git pull does not cause irreparable damage in your local working directory, but most of the time we prefer to do it slowly and do not want to rework it again.

Branch (Branches)

Before we say git pull, we need to clarify the concept of branching (branches). Many people describe what a branch is like by writing a line of code, such as:

To be precise, the concept of branching is not a line, but is similar to a direction-free graph in development

Branching is similar to a large, heavyweight collection of objects.

I think you should understand the concept of branching: it is used to tag specific code commits, each branch is identified by a sha1sum value, so the operation on the branch is lightweight-you change only the Sha1sum value.

This definition may have unintended effects. For example, suppose you have two branches, "stable" and "New-idea", with their tops in versions E and F:

  A-----C----E ("stable")       B-----D-----F ("New-idea")

So submissions (commits) A, C and E belong to "stable", while a, B, D and F belong to "New-idea". If you then use the following command to merge "New-idea" into "stable":

    git checkout Stable # change to work on   the branch ' stable '    git merge new-idea    # merge in "New-idea"

... Then you'll get this:

  A-----C----E----G ("stable")   \             /    B-----D-----F ("New-idea")

If you continue to submit in the "New Idea" and "stable" branches, you will get:

  A-----C----E----G---H ("stable")   \             /    B-----D-----F----I ("New-idea")

So now A, B, C, D, E, F, G and H belong to "stable", whereas A, B, D, F and I belong to "New-idea".

Of course, the branch does have some special properties--most importantly, if you work on a branch and create a new commit (commits), the top of the branch will advance to that commit (commits). That's what you want. When merging with git merge , you just specify the merged branch to merge into the current branch and the current progress of the current branch.

Another common scenario that suggests that the use of branching can be very helpful is assuming that you are working directly in the main branch of a project (known as the "major version"), and when you realize that what you are doing may be a bad idea, it is too late, and you would rather be working on a topic branch. If the submission diagram looks like this:

   Last version from another repository      |      V  M---N-----O----P---Q ("master")

Then you take your work separately from the following set of commands (which shows the state that was changed after they were executed):

  Git branch dubious-experiment  M---N-----O----P---Q ("Master" and "dubious-experiment")  git Checkout Master  # Be careful with this next command:make sure "git status"  was # clean, you ' re definitely on "master" and the
   
    # "Dubious-experiment" branch have the commits you were working  #  on first ... git reset--hard <sha1sum of commit n>       ("master")  M---N-------------O----P---Q ("dubious-experiment")  git Pull # Or something this Updates "master" from           # somewhere else ...  M--N----R---S ("master")             O---P---Q ("dubious-experiment")
   

It's a look I've done a lot of things in the end.

The term branching is not easy to understand, and there have been many changes in the GIT development process. But there are only two branches of git in its simplest way:

A) "Local branches", which is displayed when you enter "Git branch". For example, here's a small example:

       $ git Branch         Debian         Server       * Master

b) "Remote Trace branch (remote-tracking branches)", when you enter "Git branch-r" is displayed, such as:

       $ git branch-r       cognac/master       fruitfly/server       origin/albert       origin/ant       origin/contrib       Origin/cross-compile

As you can see from the above output, there is a "remote" tag name (e.g. origin, cognac, fruitfly) followed by a "/" in front of the name of the trace branch, and then the real name of the branch in the remote repository. ("Remote Name" is a code warehouse alias, and a local directory or URL is a meaning that you can freely define with the "Git Remote" command.) However, the "Git clone" command uses the name "origin" by default. ）

If you are interested in how the branch is stored locally, take a look at the following file:

. git/refs/head/[Local Branch]

. git/refs/remotes/[the branch being traced]

The two types of branching are very similar in some ways-they all just store a SHA1 checksum of the commit on-premises. (I emphasize "local" because many people see the "Origin/master" as saying that this branch is, in a sense, incomplete and does not have access to the remote server-this is not the case. ）
No matter how similar they are, there is a particularly significant difference:

The security method for changing a remote trace branch is to use Git fetch or as a git-push by-product, and you can't do this directly with a remote trace branch. Instead, you have to switch to the local branch and create a new commit that moves to the top of the branch.

So, the most you can do with the remote tracking branch is one of the following things:

Update a remote trace branch with git fetch

Merge the remote trace branch to the current branch

Create a local branch based on a remote trace branch

Create a local branch based on a remote trace branch

If you want to create a local branch (working on a local branch) based on a remote trace branch, you can use the following command:git branch–track or git checkout–track-b, Two commands allow you to switch to a newly created local branch. For example, you can use the git branch-r command to see the name of a remote tracing branch named "origin/refactored" that you need, and you will have the following command:

    git checkout--track-b refactored origin/refactored

In the above command, "refactored" is the name of the new branch, and "Origin/refactored" is the name of the existing remote tracing branch. (in the latest version of Git, the '-track ' option in the example is no longer required, and if the last parameter is a remote trace branch, this parameter will be added by default.) ）

The –track option sets a number of variables to maintain the dependencies of the local branch and the remote trace branch. They are useful for the following situations:

After the git pull command downloads the new remote trace branch, you can know which local branch to merge into

When you use git checkout to check your local branch, you can output some useful information:

    Your Branch and the tracked remote branch ' origin/master ' have    diverged, and respectively has 3 and 384 different
   
    commit (s) each.
   

Or:

    Your Branch is behind the tracked remote branch    ' Origin/master ' by 3 commits, and can be fast-forwarded.

The configuration variables allowed are: "Branch.<local-branch-name>.merge" and "branch.<local-branch-name>.remote", but usually you don't have to consider their settings.

After creating a local branch from the remote Code warehouse, you will notice that "git branch-r" can list many remote tracing branches, but there is only one local branch on your computer, and you need to set a parameter to the command above to specify the correspondence between the local branch and the remote branch.

There are some terminology that are easy to confuse. Note that "track", when used as a parameter "-track", refers to a remote tracing branch that is corresponding to a local branch. In the remote tracing branch, it refers to the trace branch in the Remote Code warehouse. A bit around the mouth ...

Let's look at an example of how to update the local code from the remote branch and how to push the local branch to a new remote repository.

Updating from a remote repository

If I want to update from the remote source repository to the local code warehouse, you can enter the command "git fetch Origin", which has the following input format:

  Remote:counting objects:382, done.  Remote:compressing objects:100% (203/203), done.  Remote:total 278 (Delta 177), reused 103 (Delta)  receiving objects:100% (278/278), 4.89 MiB | 539 kib/s, DONE.
   resolving deltas:100% (177/177), completed with + local objects.  From Ssh://[email Protected]/srv/git/fiji     3036acc.. 9eb5e40  debian-release-20081030-origin/debian-release-20081030   * [New branch]      debian-release-20081112-origin/debian-release-20081112   * [New branch]      debian-release-20081112.1- > origin/debian-release-20081112.1     3d619e7. 6260626  Master--     Origin/master

The most important are these two lines:

     3036acc.. 9eb5e40  debian-release-20081030-origin/debian-release-20081030   * [New branch]      debian-release-20081112-origin/debian-release-20081112

The first line indicates that the commit (commit) ID of the remote origin/debian-release-20081030 branch has been updated from 3036ACC to 9eb5e40. The part before the arrow is the name of the remote branch. The second line is the action we take to create a remote trace branch (if a remote repository has a new tags,git fetch, it will also be downloaded locally).

Experience with Git