git checkout command explanation (GO)

Git checkout--check out in everyday git operations is our common command. The two most common scenarios are creating branches and switching branches.

In the following command, a few abbreviations are used, as explained here:

Git St # git statusgit ci  # git commitgit br # git branchgit co # git checkoutgit mg # git mergegit line # git log--o Neline

Of course, you can also simply tap commands in git to add these abbreviations to your git configuration

git config--global-e

Then, you can insert the following configuration:

[Alias] st =Status CO =Checkout BR =Branch mg =Merge CI =Commit MD = Commit--Amend dt =Difftool MT =MergetoolLast = log-1HEAD CF =Config line = log--Oneline latest =for-each-ref--sort=-committerdate--format= ' ls = Log--pretty=format:\  "%c (yellow)%h%c (blue)%ad%c (red)%d%c (reset)%s%c ( Green) [%cn]\ "--decorate--date=short hist = log--pretty=format:\" %c (yellow)%h%c (red)%d%c (reset)%s%c (green) [%an]%c (blue)%ad\ "--topo-order--graph--date=short type = cat-file-t dump = cat- file-p        

In this way, you can also use these shorthand commands. Let's step into the chase.

(i) Foundation-a journey from cut cake (checkout)

Be familiar with common operations, create branches and switch branches, or check out branches.

First we create a new warehouse Gittest, and then create a new file A, why use a named it, here is deliberately for it, followed by the announcement of the branch. Oh. Perhaps the following introduction will be a bit tedious, because you have been familiar with these commands in the chest, and used quite skillfully, then you can skip this step directly.

On the master branch, commit C1 Once, then create a new branch A and switch to the a branch.

This operation will mainly use two commands:

Create a new branch: Git branch branchname

Switch to a new branch: Git checkout branchname

Then, the above two commands can also be combined as a command:

Git checkout-b branchname

(ii) Truth--head is the soul of checkout

In fact, when we switch branches and new branches, have you ever wondered how these operations work behind the scenes? The biggest hero is the. git directory head Reference, she is like a ballet dancer, from one branch of the graceful jump to another branch, although silent, but the exact incomparable.

When we are in the Master branch, you must be curious, what is the current head content? You might as well take a look.

We see that the commit hash value of C1 is the same as the current hash value of head corresponding to branch master. That is, head points to the current branch name master, and master corresponds to the current commit ID of the latest one.

OK, so let's do one more commit and see if the hash value of master corresponds to any change.

From, we can easily see that the head corresponding to the ref does not change, or master, but the master corresponding commit ID has become the C2 corresponding commit ID, that is, updated to the last commit ID.

Now, the principle of submission once, we already understand, then switch branches when it??

Now we are in the Master branch, and then we switch to a branch to see what happens.

From the analysis, on the master branch, head points to master, corresponding to the C2 's commit ID. When switching to the a branch, head also points to a, and a corresponds to the latest commit ID on the a branch. Therefore, we can conclude that the head will also point to the corresponding branch reference when switching branches.

However, when using the Checkout command, the head pointer is not changed every time. Under what circumstances has head been a staunch supporter of his goddess? Emaciated finally not regret, long make the hero tears full fly Ah! Let's take a look down.

(iii) Advanced--head understand, see how you use

The checkout command uses the following:

1. Git checkout [-Q] [<commit>] [--] <paths> ...

2. Git checkout [<branch>]

3. Git checkout [-M] [[-B |--orphan] <new_branch>] [Start_point]

The difference between usage 2 and usage 1 is that usage 1 contains a path. To avoid collisions between paths and references (or commit IDs) with the same name, you can use two consecutive hyphens as separators before <paths>. The <commit> of usage 1 is optional and, if omitted, is equivalent to checking out from staging area.

Let's look at an example:

Scenario 1, Omit <commit>

Now we are under the Master branch, and then we modify the file a, enter "C3" text to A, this time, the content in staging area is not "C3", through Git diff can be compared. Now we check out file a from the current branch staging area. Then we can use git checkout a directly.

At this point, the check out failed, Git thought we wanted to check out warehouse A. Remember why in the first step we used to create a new file a? Here finally comes in handy, because there is also branch a in the warehouse, and there is a file a in the current branch, so git silly points are not clear. What happens now? There are two ways, first, we should pay attention to the semantics when we name the branch, the branch name must have the certain meaning, cannot use the simple a,b,c to name, it is easy to cause the branch name and the file name repetition, second, the reference usage 1, uses two hyphens characters to separate. In the present case, let's use the second method.

At this time, found that the content of the workspace is covered by staging area content, "C3" text is not, of course, the head pointer has not changed, and everything has returned to calm.

Let's look at an example:

Scenario 2, do not omit <commit>

When <commit> is not omitted,,<commit> can be either a specific commit hash value or a branch name, tag name. Regardless of branch or tag, they essentially correspond to a commit hash value.

When checking out a file under the a branch, it's best to add two hyphens, or git won't be able to differentiate. The head pointer did not change throughout the process.

Summary: The 1th usage (including <paths> usage) does not change the head head pointer, which is used primarily to overwrite the corresponding file in the workspace with the specified version of the file. If <COMMIT> is omitted, files in the workspace are overwritten with staging area files, otherwise the files in the staging area and workspace are overwritten with the file in the specified submission.

Next, let's take a look at usage 2, in the first part, we know that switching branches will change the head direction, so what happens if we check out a commit? As with the checkout branch, the contents of the current branch workspace and staging area are overwritten with the contents of the commit, see example.

Currently we are on the master branch, and we have two commits, C1 and C2, and then we modify a, add the content "C3" to the a file, and add to staging area, then use checkout to C1 commit. Note that when you start checkout, Git won't allow you to switch directly, because you have modified the staging area content, it will remind you to commit and then switch, this time, you can use the-f force switch. When we look at the state again, git hints that we are no longer on any branch, and that the head pointer is also a commit value to the specific C1, entering the "split head pointer" state. In this state, to go back to master, you only need git checkout master, or you can create a new branch in this state.

If the Checkou is not followed by any parameters, then the workspace is checked, see example.

We're on the master branch and there's no change, and git checkout doesn't have any output at this point. Then, we add the content "C3" to a file, and then git checkout a bit, git will be prompted to change a file, is it very simple?

Summary: For the 2nd usage, not the time to check out a specific file, that is, when the <paths> is not specified, simply check out a commit or branch, will change the head pointer. And only when the head switch to a branch, you can track the commit, otherwise it will enter the state of the "split head pointer." If you omit <branch> after usage 2, the workspace is checked for status by default.

(iv) Familiar checkout, unfamiliar usage, mother no longer have to worry about my checkout!

1. Git branch <branch> <start point>

Create a new branch with a commit. In general, we will create a new branch on the basis of the current branch. Like Git branch new_branch.

Maybe you don't know, we can also create a branch based on a commit of the current branch. Please look!

From the visible, we want to create a new branch based on the C1 commit ID of the master branch New_branch, after the successful creation, switch to New_branch, view log, only C1, yes ~ ~ Success! Of course, you can also use git checkout-b <new_branch> <start point> this common command. 2. Git checkout--datch <branch>Switch to the Free State of the branch, by default with the last commit ID under that branch, see the example below. The current branch is a, and then using git checkout--detach master, the head switches to the state of the last commit value of master!

3. Git checkout-b <branch>

This command, you can force the creation of a new branch, why add-B? If there is already a branch with the same name as your new branch in the current repository, then using normal git checkout-b <branch> This command will be an error and the branch with the same name cannot be created. If you use the-b parameter, you can force a new branch to be created and overwrite the original branch. Please see the specific operation.

The current branch is master, and the repository already exists branch A, we first use Git checkout-b A to create a branch, will inevitably fail, and suggest that we have a branch in the warehouse, as if to say "Hi, buddy, you already have a wife, monogamy you do not understand?" You think this is India? ”。 Then we use Git checkout-b A, yes ~~,it works!

4. Git checkout--orphan <branch>

Yes, if you have accumulated countless submissions on one of your branches, you are too lazy to take care of, print out the log also makes you unable to spit groove, then this command will be your artifact, it will be based on the current branch to create a bare branch, there is no commit history, but the current branch of the content of one by one taste. The new branch, strictly speaking, is not yet a branch, because there is no commit value in the reference that head points to, and it is a true branch only after a commit is made. What are you waiting for? Give it a try!

Well, now we've finally found the organization!

5. Git checkout--merge <branch>

This command is useful when switching branches, wrapping the contents of the current branch modification together, and synchronizing to the switch branch.

There are two issues to be aware of.

First, if the content between the current branch and the switching branch is different, it is likely to cause conflicts.

Second, when you switch to a new branch, the content that is modified by the current branch is lost.

So this command, use caution!

6. Git checkout-p <branch>

This command can be used to make patches. This command is mainly used to compare the differences between the two branches and provide an interactive interface to select further operations. This command can not only compare the differences between the two branches, but also compare the differences between individual files Oh!

conclusion : At this point, about the git checkout command, for the checkout command, you are familiar with it. Of course, Git checkout has some other uses, and this article doesn't mention that you can use git checkout--help in git bash or terminal to learn more!

Http://www.cnblogs.com/hutaoer/archive/2013/05/07/git_checkout.html?utm_source=tuicool&utm_medium=referral

git checkout command explanation (GO)