Hello everyone, I am 17.
git checkout is one of the most important and commonly used commands in git. This article will explain it in detail for you.
restore workspace
One of the uses of checkout is to restore the workspace.
git checkout .
checkout . Indicates that all changes in the workspace are restored, and untracked files will not be changed.
The risk of restoring all files in the workspace is relatively high, and all modifications in the workspace will be lost, so it must be used with caution
git checkout -- a.txt
Adding – in the middle is much safer, and you can only restore a single file.
version switching
git checkout master 取出 master 分支，HEAD 指向 master
git checkout 907d3ba 取出最后提交为 commit id 为 907d3ba 这个版本,HEAD 转到 907d3ba，和 master 分离。
When the branch is taken out, HEAD will point to the current branch. Take out a certain version, HEAD will also point to it, and the branch will not move. This will cause HEAD to detach from the branch. In the case of separating HEAD, you can view, submit, and do various experiments. If you are satisfied with the results, you can open a new branch to keep these submissions:
git checkout -c <new-branch-name>
If you are not satisfied, do nothing, just switch back to the current branch.
git checkout master 修正 HEAD 指向 master 分支
It doesn't matter if you don't know which previous branch name it will checkout - also fix HEAD.
git checkout -
If you want to develop new functions, you can directly branch on a certain commit, why separate HEAD? The reason is that it is relatively lightweight. For example, you want to develop a function now, but you don't know if it is feasible, so try it out first, and then branch after confirming. If you branch directly, if you think it is inappropriate, you have to delete it. Because the branch has not been merged, it cannot be deleted, and the deletion must be forced to delete parameters.
The operation of the separation head pointer is equivalent to getting on the bus first and paying the fare later . You don't need to buy a ticket when you get on the bus and get off again. You only need to make up for the ticket when you reach the end point.
force pull branch
git checkout -B dev
Assuming that dev exists, if there is no -Bparameter , an error will be reported, adding -Bwill overwrite the original dev branch, create a new dev branch, and go to the dev branch.
Save yourself the trouble of naming it. If there is only one task in parallel, you can use the dev branch to develop each time.
branch from a commit
When we make a branch, it will start from HEAD by default. For the master branch, it is G.
If you branch out from F, you can use the second parameter to specify
git checkout -b dev F
也可以这样写
git checkout -b dev HEAD^
orphan branch
There is such a parameter --orphan, the English original meaning of orphan is orphan, if we want to make a design document branch out and write it like this
git checkout --orphan design
Because the design document and the developed code are completely independent parts, it is not suitable to be put on a branch with the developed code.
The reason why it is called an orphan branch is because this branch is completely independent and has no relationship with all previous branches. It is parallel to other branches and never intersects.
Even if the orphan branch is created from the master branch, you can't find any traces of the orphan branch git log --oneline when . Of course, it is impossible to merge an orphan branch. In fact, there is no such requirement.
When the orphan branch is first generated, there is no parent commit, no commit, and it is completely empty. Generally speaking, the temporary storage area and work area will have content, because we need to store design documents, and the original content is useless. Delete
git rm -rf .
Now that we have a clean, self-contained branch, we can add design docs and generate our first commits.
You may have doubts, since we want an orphan branch, why do we need to initialize the content for us? Because we may still have such a need: we need a starting point instead of starting from nothing.
Imagine this scenario: the project has been in development for half a year, but the market feedback is mediocre. The boss feels that this is not the way to go, and needs to find another way out, but he doesn't want to give up the current direction. Because it is a directional issue this time, the changes are relatively large. If you use a common branch, you may not be able to merge with the trunk. So the boss came up with a way to create a new orphan branch to verify new ideas completely independently. If the new direction is correct, it can replace the original direction.
It is obviously impractical to implement a project from scratch to verify a new idea. You can choose a suitable node from the project, such as an F node, and use this as a basis.
git checkout --orphan laboratory F
After the new branch is generated, all the content of the F node will be brought to the staging area and work area, and we will keep all of them and develop on this basis. The level of the laboratory and the original master branch is exactly the same, and the laboratory is equivalent to the original master branch. master just provides a starting point. How the laboratory develops later has nothing to do with the master.
choose merge
git checkout master
git merge dev
merge devWhen the conflict occurs, you can open the conflict file and modify it manually, or you can modify it automatically
git checkout --ours a.txt
git checkout --theirs a.txt
The following example illustrates how to modify automatically.
First create a merge conflict scene. The starting point is the master branch. Modify the first line of a.txt in master branch and dev branch at the same time,
echo init >a.txt
git add a.txt
git commit -m 'add a.txt'
git checkout -b dev
echo dev >a.txt
git add a.txt
git commit -m 'alter a.txt'
git checkout master
echo master >a.txt
git add a.txt
git merge dev
Look at the content of a.txtcat a.txt
<<<<<<< HEAD
master
=======
dev
>>>>>>> dev
The above is the modification of master, and the one below is the modification of dev.
If you regret it now and want to cancel the merge and restore to the state before the merge,
git merge --abort
Automatic modification with git checkoutthe command . We can choose to keep the content of the master branch
git checkout --ours -- a.txt
Check the content of a.txt, it has returned to normal.
master
If it is found that this is not the result we want, the conflict scene can be restored
git checkout -m -- a.txt
View a.txt, and restored to the conflict state. This time we select the content of dev.
git checkout --theirs -- a.txt
After checking that the content is correct, add it to the temporary storage area.
git add a.txt
The conflict is resolved, but the merge is not yet complete.
git merge --continue
At this time, the editor pops up, you can modify the submission information, and the modified content will be automatically submitted after confirmation. mergeFinish.
Newly added git switch
You will find that checkout hosts many branch-related commands. In order to make the command clearer, the new version of git adds the switch command.
Checkout can do everything switch can do.
The function of the switch command is very pure, which is to switch branches. If the branch does not exist, create a new branch by the way.
Give two common examples.
| switch | checkout |
|---|---|
| git switch master | git checkout master |
| git switch -c dev | git checkout -c dev |
| git switch --orphan | git checkout --orphan |
When cutting branches, it is recommended to submit the contents of both the workspace and the temporary storage area
Newly added git restore
For the git switchsame , the new version adds git resotrethe command.
git resotreThe responsibility of is to restore the workspace and the staging area. checkoutIt can do whatever it can do. What it can do, checkoutit probably can't.
--worktreegit restoreis the default parameter for
git restore a.txt 把暂存区 a.txt 的内容恢复到工作区
git restore . 恢复工作区的所有内容。
git restore --staged a.txt 把 HEAD 的 a.txt 恢复到暂存区
git restore --source=HEAD --staged --worktree a.txt 恢复工作区和暂存区
–source means where it comes from, the default is HEAD --staged means restore to the staging area, –worktree means restore to the work area. There are abbreviations for these three parameters.
git restore -s HEAD -SW a.txt
When merge conflict occurs, restore can also be used to resolve the conflict, the usage is the same as checkout.