Git branch

Almost all version control systems support branching in some form. Using branches means that you can separate your work from the development mainline without affecting it. On many version control systems, this is a slightly inefficient process — it is often necessary to create a complete copy of the source directory. For large projects, this process can take a lot of time. Git is incredibly lightweight in the way it handles branches, creating new branches is almost instantaneous, and switching between branches is equally easy. Unlike many other version control systems, Git encourages frequent use of branching and merging in your workflow, even many times a day.

Git’s default branch name is master. Git’s master branch is not a special branch. It’s just like any other branch. The reason almost every repository has a master branch is because git init creates it by default and most people don’t bother to change it. Git branches are essentially just mutable Pointers to submitted objects that have multiple commits on one branch (the encapsulation of tree objects). After multiple commits, you actually have a master branch that points to the last committed object. The Master branch automatically moves forward on each commit. The header in the figure below points to F30AB. As shown below:

1. Create a branch

Git branch Specifies the branch nameCopy the code

This creates a pointer to the submitted object where it is currently located. As shown below:

2. Switch branches

Git Checkout branch nameCopy the code

This is a pointer to the test branch, as shown below:

3. Work on the new branch and commit

The HEAD branch automatically moves forward with the commit operation, and the final branch diagram looks like this:

4. Switch to the Master branch again

   git checkout master
Copy the code

This order does two things. Restore the working directory to the snapshot that the master branch pointed to. That is, if you make changes now, the project will start with an older version. In essence, this means ignoring changes made by the Testing branch in order to develop in the other direction. As shown below:

Note: Switching branches will change the files in your working directory. When switching branches, be aware that the files in your working directory will change. If you switch to an older branch, your working directory will revert to what it looked like when the branch was last committed. If Git can’t do this cleanly, it will forbid branch switching.

5. Now work on the master branch and commit

Now, the commit history of this project has bifurcated, because you created a new branch, switched over to do some work, and then switched back to the Master branch to do some work. The two changes above are for different branches: you can constantly switch back and forth and work between branches, merging them when the time is right. The diagram below:

Merge master and new branch

Git merge New branch nameCopy the code

At this point, the master branch already has the code changed on the new branch.

Remote repository for team collaboration

Remote trace branch

The remote trace branch is a reference to the state of the remote branch. They are local references that you can’t move. Once you make network communications, Git moves them around for you to accurately reflect the state of the remote repository.

Tracking branch

Checking out a local branch from a remote trace branch automatically creates what is called a “trace branch” (the branch it tracks is called an “upstream branch”). Trace branches are local branches that are directly related to remote branches.

The local branch

A local branch created by a local repository.

The trace branch is a bridge between the local branch and the remote trace branch. When we clone, a local branch of master is automatically generated by default (the corresponding remote trace branch has been traced).

When the local branch does not track the remote trace branch

• When you create a branch and push it to a remote repository

  git push origin master
Copy the code

Although the command above can push local branches to remote branches, can we simplify it more? The answer is definitely yes, git push is ok, but now there will be a problem, as shown in the figure below:

The local branch does not trace the remote branch, so we execute the following command:

Git branch -u Repository name (alias)/branch nameCopy the code

However, there is another problem, as shown in the following figure:

Why is that? There is no Origin/Master remote trace branch because the branch was never pushed to the remote repository. Next, execute this command:

git push origin master
Copy the code

At this point, the remote trace branch already exists, as shown below:

Then execute the command above and you are done.

Finally, when we change the master branch, we just do git push. When we want to update the master branch, we just do Git pull.

Git push -u origin master git push -u origin master

• Someone else created a branch and pushed it to the remote repository, so we need to pull the branch ourselves

First we need to execute the following command

Git fetch Repository name Branch nameCopy the code

But something like this happens, as shown below:

According to the result of executing the command, we now have no local branch wang, so we need to create and merge it manually. You need to run the following command:

In this way, we have got the branch submitted by others, because now the local branch does not track the remote tracking branch, so every time we talk to a new branch, we have to execute the above command, which is very tedious, is there any solution? Of course there is, as in the first case above, just trace the remote trace branch.

Git fetch can be omitted by executing git checkout -b to remotely trace the branch nameCopy the code

Future updates can be git pulled directly.

So when the Git team is assisting with development, it is important to note that the local branch tracks the remote trace branch.