Today we are going to talk about a very, very important feature in Git: Branch.

Git Branch is the most important concept in Git, if not the most important. Because the most important use scenario for Git is collaborative development, where people work together on a project to develop different features. Because of the concept of branching, people can develop without interfering with each other. Without this feature, git’s other features, no matter how good they are, may not work.

Therefore, to some extent, it can be understood that the most important thing to learn Git is to learn the related content of branches. Of course, there are so many branches and commands that it’s unrealistic to expect to learn them all at once. But with some understanding of the concept, it should be possible to use some basic commands.

Before we understand the concept of branching, we need to take a look at Git’s structure.

The structure of the Git

A branch is a branch of a tree. A branch can also be viewed as a link in a tree because the relationship between all commit nodes in a Git repository is actually a tree. One small problem with this is that if a branch is a link, then each node on that link represents a COMMIT, which means a snapshot of the code, sort of like a game archive.

There are multiple Commits on a branch, and a game can have multiple saves, but obviously only one can be loaded at the moment. So git uses a pointer to the currently loaded commit, which means that vertically a branch represents a series of commits, but in Git the branch is actually a pointer, a pointer that switches between commits.

Let’s look at an example. For example, when we start we only have the default branch master, which points to the current commit.


Now we create a test branch using git branch test. After executing it, we simply add a pointer to the current commit. The structure in Git looks like this:


When we make a change commit on the test branch, Git produces a new commit and moves the test pointer, leaving the master pointer in place.


If we go back to the master and commit, a new node will be created, and this node will be separated from the test node, forming a new link, and thus forming a tree.


Branch and HEAD Pointers

Branch creation, as we have just described, can be done by adding the desired branch name to Git Branch. After using this command, git creates a new pointer internally to the current commit.

One question is how does Git know where our current code is? Even if you know which branch your code is on, how can you determine which node it is on? Git also has a special pointer inside it called HEAD, which points to the current repository location. When we submit code, not only the branch Pointers will move forward, but the HEAD pointer will move along with it.

The HEAD pointer can be moved not only forward, but also to any node, even if it is not on the current branch. To move the HEAD pointer, use the Git checkout command, which specifies that the HEAD pointer be moved to another location. This can be either a branch or a node identified by its COMMIT ID.

For example, if we’re in the master branch and we want to switch to the test branch, we just need to run:

git checkout master
Copy the code

You can also create a branch using the git checkout command with the -b parameter. Git checkout -b test will automatically switch to the newly created test branch if the current test branch does not exist.


Once you commit on your new branch, you can use the git log –oneline –decorate command to see where each branch points to. The oneline here is to compress the log onto a line that you use to see where the branch points to.


We can see that the test and master branches point to different commits, and that our HEAD is currently on test, indicating that we are currently in the Test branch. Git checkout (18a417); git checkout (18a417); git checkout (18a417); The commit is on the master branch, which is upstream from the test branch. Using the command, we will automatically jump the HEAD to the Master branch.


After using the ZSH tool, it will tell me that the current location is 3 commits behind the latest location that the master branch points to.

This also verifies that the HEAD pointer can jump at will. Git reset HEAD^ git reset HEAD^ git reset HEAD^ If it is the first multiple submissions, we can use the form ~ plus a number to represent it. For example, master~3, highlighted in red, represents three commits on the master node.

Branch merge

Finally, a brief word about branch merging. We are in the process of co-developing with Git, although everyone is in their own branch. But eventually the code has to be merged so it can be used. Merge code in Git is represented by branch merge.

For example, I added the current article to the test branch, which is obviously not feasible, because users cannot understand what each branch does and the code logic in it. So most branches are only temporary, used to complete a function temporarily, and when that function is complete, they are generally merged back into the master branch to incorporate all changes.

The way to merge is very simple, we just need to checkout the target branch we want to merge. So if we want to merge to master, we’re going to checkout to master. Then use git merge test to merge with the test branch.


After the merge, the merge is successful if no errors are reported. It shows the code changes that have been merged, and we notice that there is a word fast-forward in the log, which stands for fast merge. The meaning of fast merge is also simple, because our test branch cuts out from the master branch. The master branch hasn’t changed since, so when we merge, all we need to do is move the master pointer to the test branch.

We use the figure to show that before the merger:


After the merger:


So what happens if we also make a change on the master branch, instead of being directly upstream of the branch we want to merge?


First we create a branch called test_merge, in which we create a file called A.txt. Then we cut back to the master branch and create b.txt. Finally we merge the two branches.

Git log () git log ()


There is a commit added to the log, which I did not commit, but it generated automatically. Let’s also use the graph to show it. This is before the merger:


After the merger:


Since there is no longer a direct upstream/downstream relationship, Git creates a new COMMIT to merge the code of the two branches. When we’re done merging, we can remove all the branches that don’t work. Git branch -d test

Of course, git merge is not always smooth sailing, and conflicts will inevitably occur. A conflict is when two people change the same piece of code and Git doesn’t know which one to keep, so it prompts the programmer to fix it. Git merge: Git merge: Git merge: Git merge

That’s all for today’s article. I sincerely wish you all a fruitful day. If you still like today’s content, please join us in a three-way support.

Original link, ask a concern

This article is formatted using MDNICE

– END –