The essence of GIT’s instructions is really easy to understand


The essence of GIT instructions is really easy to understand

From: nuggets by Bezier



As the most powerful code management tool in the world, Git is familiar to everyone, but as far as I know, a large number of people stay in clone, commit, pull, push At this stage, do you have no bottom for rebase and only dare to use merge?

Blind when you see the version back? Don’t ask me how I know. The question is: “I used to be like this ~ ~”.

In view of these problems, today I will share my cognition and understanding of git in recent years, explain git from the essence as much as possible, and help you understand the underlying principles of GIT step by step. I believe that after reading this article, you can change your attitude and use various instructions of GIT more coquettishly.


  • 1. Basic concepts

  • 1.1 git’s advantages

  • 1.2 document status

  • 1.3 commit node

  • 1.4 HEAD

  • 1.5 remote warehouse

  • 2. Branch

  • 2.1 what is a branch?

  • 3. Detailed explanation of the order

  • 3.1 submission of relevant documents

  • 3.2 branch related

  • 3.3 merger related

  • 3.4 fallback related

  • 3.5 remote correlation

1. Basic concepts

1.1 git’s advantages

Git is a distributed code management tool. Before discussing distribution, we can’t avoid mentioning what is a central code management warehouse

  • Central: all codes are saved in the central server, so the submission must rely on the network, and each submission will be brought into the central warehouse. If it is collaborative development, code consolidation may be triggered frequently, which will increase the cost and cost of submission. The most typical is SVN
  • Distributed: it can be submitted locally without relying on the network, and each submission will be automatically backed up locally. Each developer can send a copy of the remote warehouse clone locally and will bring the submission history together. The representative is GIT

What are the advantages of GIT over SVN?

For example: “balabalabala wrote a lot of code and suddenly found something wrong. I want to go back to an hour ago”. In this case, GIT has obvious advantages, because the cost of commit is relatively small, and all submission records will be saved locally, which can be backed back at any time.

This is not to say that SVN cannot complete this operation, but git’s fallback will be more elegant. Git has many advantages over central tools, so I won’t list them one by one. Those interested can understand it by themselves.

1.2 document status

In git, files can be divided into three states: modified, staged, and committed

  • modifyGit can sense which files in the working directory have been modified, and then add the modified files to the modified area

  • Temporary storage: submit the modified files in the working directory to the temporary storage area through the add command and wait for them to be committed

  • Submit: commit the staging area file to the GIT directory and save it permanently

1.3 commit node

For ease of expression, I will submit this article through a node called commit

In git, each submission will generate a node, and each node will have a hash value as the unique identifier. Multiple submissions will form a linear node chain (regardless of merge), as shown in Figure 1-1

The essence of GIT's instructions is really easy to understand


Above the node is the hash value calculated by SHA1

The C2 node contains the content submitted by C1. Similarly, the C3 node contains the content submitted by C1 and C2

1.4 HEAD

Head is a very important concept in GIT. You can call it pointer or reference. It can point to any node, and the node pointed to is always the current working directory. In other words, the current working directory (that is, the code you see) is the node pointed to by head.

Take Figure 1-1 as an example. If head points to C2, the working directory corresponds to C2 node. How to move the head pointing will be discussed later. Don’t tangle here.

At the same time, head can also point to a branch and indirectly point to the node to which the branch points.

1.5 remote warehouse

Although git will save the code and history locally, it will eventually submit to the remote warehouse on the server. Through the clone command, you can download the code of the remote warehouse to the local. At the same time, you can synchronize the submission history, branch, head and other states to the local. However, these States will not be updated in real time. You need to manually pull them from the remote warehouse. When and how to pull them will be discussed in the following chapters.

After you finish developing the new code for your colleagues in the warehouse, you can also pull the new code from the warehouse remotely through the intermediary.


Because you and your colleagues will take the code of the remote warehouse as the benchmark, you should always ensure the code quality of the remote warehouse and remember not to submit the untested code to the remote warehouse

2. Branching

2.1 what is a branch?

Branch is also a very important concept in GIT. When a branch points to a node, the content of the current node is the content of the branch. Its concept is very close to that of head. It can also be regarded as a pointer or reference. The difference is that there can be multiple branches, but there is only one head. Different branches are usually established according to function or version.

What’s the use of that branch?

  • For example: your app has gone through a lot of hardships and finally released v1 Version 0, due to urgent demand v1 After 0 went online, it started v1 1. When your development was on the rise, QA students said that users fed back some bugs and needed to fix them, and then redistribute them to fix v1 0 must be based on v1.0 0 code, but you have developed part of V1 1. What’s going on now?

The above problems can be solved gracefully by introducing the concept of branch, as shown in Figure 2-1

The essence of GIT's instructions is really easy to understand

  • First look at the schematic diagram on the left, assuming that C2 node is V1 0 version code. After going online, create a new branch ft-1.0 based on C2
  • Look at the diagram on the right, in V1 After 0 goes online, v1.0 can be developed in the master branch 1. Submit the content after receiving the feedback from QA classmates v1 1 code generation node C3, then switch to the ft-1.0 branch for bug repair, submit the code generation node C4 after repair, and then switch to the master branch and merge the ft-1.0 branch. Now we have solved the above problem

In addition, many things can be done by using branches. For example, there is a demand that is uncertain whether to go online, but it must be done first. At this time, a branch can be created separately to develop the function. When it needs to go online, it can be directly merged into the main branch. There are many scenarios applicable to branches, so I won’t list them one by one.


When a branch is created at a node, the code corresponding to the node will not be copied, but the new branch will be directed to the node, so the space overhead can be greatly reduced. Be sure to remember that no matter head or branch, they are only references, and the magnitude is very light

3. Command details

3.1 submission of relevant documents

As mentioned earlier, if you want to submit code, you must first add it to the temporary storage area. Git is implemented through the command add

To add a file to the staging area:

Git add file path

Add all files to staging area:

git add .

Git also provides commands to undo workspaces and staging areas

Undo workspace changes:

Git checkout -- file name

Empty staging area:

Git reset head file name


After adding the changed file to the temporary storage area, it can be submitted. After submission, a new submission node will be generated. The specific commands are as follows:

Git commit - M "description of this node"

3.2 branch related

Create branch

After creating a branch, the branch will point to the same node as head. Generally speaking, the new branch will point to where head points. The command is as follows:

Git branch branch name

Switch branch

After switching branches, by default, head will point to the current branch, that is, head indirectly points to the node to which the current branch points

Git checkout branch name

At the same time, you can also switch immediately after creating a branch. The command is as follows:

Git checkout - B branch name

Delete branch

In order to ensure the simplicity of warehouse branches, a branch should be deleted when it has completed its mission. For example, as mentioned above, open a branch to complete a function. When this function is merged into the main branch, this branch should be deleted in time.

The delete command is as follows:

Git branch - D branch name

3.3 merger related

The command of merging is the most difficult and important. There are about three merge commands we commonly use: merge, rebase and cherry pick


Merge is the most commonly used merge command. It can merge the code of a branch or a node into the current branch. The specific commands are as follows:

Git merge branch name / node hash value

If the branch to be merged is completely ahead of the current branch, as shown in Figure 3-1

The essence of GIT's instructions is really easy to understand


Since branch FT-1 is completely ahead of branch ft-2, that is, FT-1 completely contains ft-2, ft-2 will trigger fast forward after executing “git merge FT-1”. At this time, the two branches point to the same node, which is the most ideal state.

However, in actual development, we often encounter the following situations: as shown in Figure 3-2 (left)

The essence of GIT's instructions is really easy to understand


This situation cannot be closed directly. When ft-2 executes “git merge FT-1”, GIT will merge nodes C3 and C4, then generate a new node C5, and finally point ft-2 to C5, as shown in Figure 3-2 (right)


If C3 and C4 modify the same sentence code in the same file at the same time, the merging will be wrong at this time, because git does not know which node should be used as the standard, so we need to merge the code manually at this time


Rebase is also a merge instruction. The command line is as follows:

Git rebase branch name / node hash value

Unlike merge, rebase merging does not seem to generate new nodes (in fact, it does, but only makes a copy), but directly accumulates the nodes to be merged, as shown in Figure 3-3

The essence of GIT's instructions is really easy to understand


When ft-1.0 in the diagram on the left executes git rebase master, a copy of C4 node will be copied behind C3, that is, C4 ‘, C4 corresponds to C4’, but the hash value is different.

Rebase has a more linear and clean submission history than merge, making the parallel development process look like serial, which is more in line with our intuition. Since rebase is so easy to use, can we abandon merge? In fact, it’s not. Here are some advantages and disadvantages of merge and rebase:

Advantages and disadvantages of merge:

  • Advantages: each node is arranged strictly according to time. When a merge conflict occurs, you only need to resolve the conflict between the nodes pointed to by the two branches
  • Disadvantages: when merging two branches, new nodes will be generated and forked with high probability, and the submission history will become a mess over time

Rebase advantages and disadvantages:

  • Advantages: it will make the submission history look more linear and clean
  • Disadvantages: Although the submission looks linear, it is not really sorted by time. For example, in Figure 3-3, whether C4 is submitted earlier or later than C3, it will eventually be placed after C3. In addition, when merging conflicts occur, theoretically, it is possible to handle several conflicts when several nodes rebase to the target branch

The author doesn’t agree with some views on using rebase only on the network. If different branches merge and use rebase, they may need to solve conflicts repeatedly, which is not worth the loss. However, if it is pushed from local to remote and corresponds to the same branch, rebase can be given priority. Therefore, my view is to use merge and rebase reasonably according to different scenarios. If you think both are OK, rebase is preferred


The merge of cherry pick is different from merge and rebase. It can select some nodes to merge, as shown in Figure 3-4

Command line:

Git cherry pick node hash value
The essence of GIT's instructions is really easy to understand


Assuming that the current branch is the master, after executing the GIT cherry pick C3 (hash value), the C4 (hash value) command will directly grab the C3 and C4 nodes and put them behind, corresponding to C3 ‘and C4’

3.4 fallback related

Detach head

By default, head points to the branch, but you can also take head from the branch and directly point to a node. This process is to separate head. The specific commands are as follows:

Git checkout node hash value // you can also directly break away from the branch and point to the current node git checkout -- detach

Because the hash value is a long string of garbled codes, it is troublesome to separate the head by using the hash value in actual operation. Therefore, GIT also provides the command that the head directly points to the previous or N nodes based on a special location (branch / head), that is, relative reference, as follows:

//Head separates and points to the previous node git checkout branch name / head^
//Head separates and points to the first n nodes git checkout branch name ~ n

What’s the use of separating the head from the pointing node? For example: if the development process finds a problem with the previous submission, you can point the head to the corresponding node and submit it after modification. At this time, you certainly don’t want to regenerate into a new node, but you just need to add — amend when submitting. The specific commands are as follows:

git commit --amend

Back off

Fallback scenarios are quite common in normal development. For example, you write a lot of code and submit it. Later, you find that there is a problem with the writing, so you want to return the code to the previous submission. This scenario can be solved by reset. The specific commands are as follows:

//Back n submitted git reset head ~ n

Reset is very similar to relative reference, except that reset will cause the branch and head to fall back together.

3.5 remote correlation

When we come into contact with a new project, the first thing is to take down its code. In git, we can copy a copy of the code from the remote warehouse to the local through clone. The specific commands are as follows:

Git clone warehouse address

As I mentioned in the previous chapter, clone not only copies the code, but also removes the reference (branch / head) of the remote warehouse and saves it locally, as shown in Figure 3-5:

The essence of GIT's instructions is really easy to understand


Where origin / master and origin / FT-1 are branches of the remote warehouse, and these remote reference states will not be updated to the local in real time. For example, the origin / Master branch of the remote warehouse adds a submission, which is not perceived by the local at this time, so the local origin / Master branch still points to the C4 node. We can manually update the remote warehouse status through the fetch command


It’s not the ability that exists on the server that is called a remote warehouse. You can also use the clone local warehouse as a remote warehouse. Of course, in actual development, we can’t treat the local warehouse as a public warehouse. It’s just to help you understand the distributed warehouse more clearly


Generally speaking, the fetch command is a download operation. It will download the status of newly added remote nodes and references (branches / heads) locally. The specific commands are as follows:

Git fetch remote warehouse address / branch name


The pull command can pull the code from a reference in the remote warehouse. The specific commands are as follows:

Git pull remote branch name

In fact, the essence of pull is fetch + merge. First update all the states of the remote warehouse to the local, and then merge. After merging, the local branch will point to the latest node

In addition, the pull command can also be combined through rebase. The specific commands are as follows:

Git pull -- rebase remote branch name


The push command can push the local submission to the remote. The specific commands are as follows:

Git push remote branch name

If you push directly, it may fail. Because there may be conflicts, you will often pull it before pushing. If there are conflicts, resolve them locally. After the push is successful, the local remote branch reference will be updated and point to the same node as the local branch.

in summary

  • Whether head or branch, they are just references. Reference + node is the key to git’s distribution

  • Merge has a clearer time history than rebase, which makes submissions more linear and should be used first

  • You can view the code corresponding to each submission by moving head

  • Clone or fetch will save all the submissions and references of the remote warehouse in a local copy

  • The essence of pull is actually fetch + merge. You can also join — rebase and merge through rebase