Use of version management tool git (III) – git branch


Almost all version control systems support branching in some form. Using branches means that you can separate your work from the development main line so as not to affect the development main line. In many version control systems, this is a slightly inefficient process — often a complete copy of the source directory needs to be created. For large projects, such a process will take a lot of time.
Some people call git’s branch model its “must kill technology feature”, which makes git stand out from many version control systems. Why is git’s branching model so outstanding? The way git handles branches is incredibly lightweight. Creating new branches can be done almost instantaneously, and switching between different branches is just as convenient. Unlike many other version control systems, GIT encourages the frequent use of branching and merging in workflow, even many times a day. By understanding and mastering this feature, you will realize that Git is so powerful and unique, and really change the way you develop.
Before introducing the GIT branch, let’s talk about how git saves data?

1、 How does git save data

Record snapshots directly instead of comparing differences

The main difference between GIT and other version control systems, including subversion and approximation tools, is the way git treats data. Conceptually, most other systems store information in the form of a file change list. Such systems (CVS, subversion, perforce, bazaar, etc.) see the information they hold as a set of basic files and the differences that each file accumulates over time.
Use of version management tool git (III) - git branch
Git does not treat or save data in the above manner. Instead, Git is more like looking at data as a set of snapshots of a small file system. Every time you submit an update or save the project status in git, it mainly takes a snapshot of all the files at that time and saves the index of the snapshot. For efficiency, if the file is not modified, GIT will no longer re store the file, but only keep a link to the previously stored file. Git treats data more like a snapshot stream.
Use of version management tool git (III) - git branch
This is an important difference between GIT and almost all other version control systems.
When committing, GIT will save a commit object. Knowing how git saves data, we can naturally think that the commit object will contain a pointer to the snapshot of the temporary content. But not only that, the submission object also contains the author’s last name
Name and mailbox, the information entered when submitting, and a pointer to its parent object. The submission object generated by the first submission does not have a parent object. The submission object generated by the ordinary submission operation has a parent object, while the submission object generated by the merger of multiple branches has multiple parent objects. For more visual illustration, let’s assume that there is a working directory containing three files to be temporarily staged and submitted. The staging operation will calculate the checksum for each file, then save the file snapshot of the current version to the GIT warehouse, and finally add the checksum to the staging area for submission:

git add README test.rb LICENSE
git commit -m ‘The initial commit of my project’

When git commit is used for submission, GIT will first calculate the checksum of each subdirectory, and then save these checksums as tree objects in Git warehouse. Git then creates a submission object that contains not only the information mentioned above, but also a pointer to the tree object (the project root directory). In this way, GIT can reproduce the saved snapshot when necessary.
Now, there are five objects in Git warehouse: three blob objects (holding file snapshots), a tree object (recording directory structure and blob object index) and a submission object (containing pointers to the above tree objects and all submission information).
Use of version management tool git (III) - git branch

If you submit again after making some changes, the submitted object generated this time will contain a pointer to the last submitted object (parent object).

Use of version management tool git (III) - git branch

(refer to progit for the above content)
The branch of Git is essentially just a variable pointer to the submitted object. The default branch name of Git is master. After multiple commit operations, you actually have a master branch pointing to the last commit object. It will automatically move forward in each submission operation.
(the “master” branch of Git is not a special branch. It is no different from other branches. Almost every warehouse has a master branch because it is created by the GIT init command by default.)
Use of version management tool git (III) - git branch
2、 Branch related concepts and operations
After understanding the above concepts, let’s assume that two people are required to develop different functions for the same project. How can we ensure that they do not affect each other in the development process— Branching can solve this effect

2.1 creation and consolidation of branches

Let’s take a simple example of branch creation and branch merging. You may use a similar workflow in actual work. You will go through the following steps

  1. Develop a website.
  2. To implement a new requirement, create a branch.
  3. Work on this branch.

At this time, you suddenly receive a call saying that there is a very serious problem that needs urgent repair. You will handle it as follows:

  1. Switch to your production branch.
  2. Create a new branch for this urgent task and fix it in it.
  3. After the test passes, switch back to the online branch, then merge the patched branch, and finally push the changes to the online branch.
  4. Switch back to the branch where you originally worked and continue working.

New branch
First, suppose you are working on the master branch of your project and there are already some submissions.
Now you need to repair a problem on the line (issuse 52). At this time, you need to create a new branch to repair the problem and switch to the branch
Use the command:

git checkout -b issuse52

It is short for the following two commands:

git branch issuse52
git checkout issuse52

Note: when switching branches, make sure that the staging area is clean. Switching branches will fail.
It took you some time to fix the issuse and push the repaired code to the remote library.
At this time, you can switch to the original master branch to continue the previous work
Remember: when you switch branches, GIT will reset your working directory to look like it was the last time you committed on that branch. As like as two peas, the Git will automatically add, delete, and modify files to ensure that your working directory is exactly the same as the last submission.
You can run your tests, make sure your changes are correct, and then merge them back to your master branch to deploy them online. You can do this by using the GIT merge command:

git checkout master
git merge issuse52
Updating f42c576..3a0874c
 index.html | 2 ++
 1 file changed, 2 insertions(+)

When merging, you should notice the word “fast forward”. Since the submission pointed to by the current master branch is directly upstream of your current submission (submission about hotfix), GIT simply moves the pointer forward. In other words, when you try to merge two branches, if you can go to another branch along one branch, then Git will simply push the pointer forward (pointers to the right) when merging the two, because there is no need to resolve the difference in the merging operation in this case, which is called fast-forward. Now that the latest modification is in the commit snapshot pointed to by the master branch, you can start publishing the repair.
After the solution to this urgent problem is released, you are ready to return to your work before being interrupted. However, you should delete hotfix points first
Branch, because you no longer need it – the master branch has pointed to the same location. You can use git with the – D option
Branch command to delete a branch:

git branch -d issuse52
Deleted branch issuse52 (3a0874c).

2.2 branch merging in case of conflict

Sometimes the merge operation does not go so smoothly. If you make different changes to the same part of the same file in two different branches, GIT can’t merge them cleanly. If your changes to #53 questions and hotfix involve the same content of the same file
Merge conflicts arise when merging them:

git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

At this point, GIT makes a merge, but does not automatically create a new merge submission. Git will pause and wait for you to resolve the conflict arising from the merger.
You can use the GIT status command at any time after the merge conflict to view those files that are in the unmerged state because they contain the merge conflict:

git status
On branch master
You have unmerged paths.
 (fix conflicts and run "git commit")
Unmerged paths:
 (use "git add <file>..." to mark resolution)
 both modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")

Any files to be resolved because they contain merge conflicts are identified as unmerged. Git will add standard conflict resolution tags to files with conflicts, so that you can open these files with conflicts and resolve them manually. The conflicting file will contain some special sections, which look like the following:

<<<<<<< HEAD:index.html
<div id="footer">contact : [email protected]</div>
<div id="footer">
 please contact us at [email protected]
>>>>>>> iss53:index.html

This means that the version indicated by head (that is, the location of your master branch, because you have checked out this branch when running the merge command) is in the upper half of the section (= = = = = = =), and the version indicated by iss53 branch is in the upper half of = = = = = = = =)
The lower half. In order to resolve the conflict, you must choose to use=======
One of the two parts of the split, or you can merge them yourself. For example, you can solve this by changing this paragraph to the following
Conflict resolution:

<div id="footer">
please contact us at [email protected]

The above conflict resolution solution only retains the modification of one branch, and < < < <, =========, and > > > > > > these lines are completely deleted. After you have resolved the conflicts in all files, use the GIT add command for each file to mark it as resolved. Once these conflicting files are staged, GIT marks them as resolved.

2.3 branch development workflow

Next, we introduce some common workflow of development using branches. Because of the convenience of branch management, these typical working modes are derived. You can choose one according to the actual situation of the project.
Long term branch
Because git uses a simple three-party merge, it is not difficult to merge one branch into another repeatedly over a long period of time. In other words, you can have multiple open branches at different stages of the whole project development cycle; You can periodically merge certain feature branches into other branches. Many developers who use git like to work in this way. For example, only keep completely stable code on the master branch – maybe only
Only code that has been released or will be released. They also have parallel branches called development or next, which are used for subsequent development or stability testing – these branches do not have to be absolutely stable, but once they reach a stable state, they can be merged into the master branch. In this way, after ensuring that these completed feature branches (short-term branches, such as the previous iss53 branch) can pass all tests and will not introduce more bugs, they can be merged into the trunk branch and wait for the next release. In fact, what we just discussed is the pointer that keeps moving right with your submission. The pointer of the stable branch always lags far behind in the submission history, while the pointer of the leading branch is often higher.
It may be better to think of them as work silos. Those tested submissions will be selected to a more stable pipeline.
Use of version management tool git (III) - git branch
Characteristic branch
The feature branch is applicable to projects of any size. A feature branch is a short-term branch that is used to implement a single feature or its related work. In git, it is common to create, use, merge, and delete branches multiple times a day.
You have seen this usage in the iss53 and hotfix feature branches you created in the previous section. You submitted some updates in the feature branch (iss52) used in the previous section, and after they were merged into the trunk branch, you deleted them. This technology enables you to quickly and completely perform context switching – because your work is scattered into different pipelines, in which each branch is only related to its target characteristics, it is easier to see what changes you have made when doing work such as code review. You can keep the changes in the feature branch for a few minutes, days or even months, and merge them when they mature, regardless of the order in which they are established or the progress of their work.
Keep in mind that when you do so many operations, these branches are all stored locally.
When you create and merge branches, all this happens only in your local git Repository – there is no interaction with the server.

2.4 remote branch

Remote references are references (pointers) to remote warehouses, including branches, labels, and so on. You can explicitly get the complete list of remote references through git LS remote (remote), or get more information about remote branches through git remote show (remote). However, a more common approach is to use remote tracking branches.
A remote trace branch is a reference to the status of a remote branch. They are local references that you cannot move. When you do any network communication operations, they will move automatically. Remote tracking branches are like bookmarks of the status of those branches when you last connected to a remote warehouse.

They are named as (remote) / (Branch). For example, if you want to see the status of the master branch when you last communicated with the remote warehouse origin, you can view the origin / Master branch. You work with colleagues to solve a problem and they push an iss52 branch. You may have your own local iss53 branch; However, the branch on the server will point to the submission of origin / iss53.
This may be a little difficult to understand, for example. Suppose you have a git server on in your network. If you clone from here, GIT’s clone command will automatically name it origin, pull all its data, create a pointer to its master branch, and locally name it origin / master. Git will also give you a local master branch that points to the same place as the master branch of origin, so that you have a foundation for work.
If you do some work in the local master branch, at the same time, others push to submit to and update its master branch, then your submission history will go in different directions. In addition, as long as you do not connect to the origin server, your
The origin / Master pointer will not move.
To synchronize your work, run the GIT fetch origin command. This command finds which server “origin” is (in this case, it is GIT. Ourcompany. Com), grabs data that is not available locally, updates the local database, and moves origin / master
The pointer points to a new, updated location.
When you want to publicly share a branch, you need to push it to a remote warehouse with write permission. Local branches are not automatically synchronized with remote warehouses – you must explicitly push the branches you want to share.
If you want to work with others in a branch called serverfix, you can push it like pushing the first * * branch. Run git push (remote) (Branch):

git push origin serverfix
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
 * [new branch] serverfix -> serverfix

The next time other collaborators grab data from the server, they will generate a remote branch origin / serverfix locally, which refers to the serverfix branch of the server:

git fetch origin
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
 * [new branch] serverfix -> origin/serverfix

It should be noted that when a new remote trace branch is captured, an editable copy (copy) will not be automatically generated locally. in other words
In this case, there will be no new serverfix branch — only an origin / serverfix pointer that cannot be modified.
You can run git merge origin / serverfix to merge these jobs into the current branch. If you want to be in your own
Working on the serverfix branch, you can build it on the remote trace branch:

git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'

This will give you a local branch for work, starting at origin / serverfix.
Trace branch
Checking out a local branch from a remote tracking branch automatically creates a so-called “tracking branch” (the branch it tracks is called “upstream branch”).
A trace branch is a local branch that has a direct relationship with a remote branch. If you enter git pull on a tracking branch, GIT can automatically identify which server to grab and merge to which branch.
When cloning a warehouse, it usually automatically creates a master branch that tracks origin / master.


The above describes how to create and switch to a new branch and switch between different branches to
And merge local branches, push the content of local branches to git’s servers, obtain the latest content of remote branches, and use shared branches to collaborate with others.