One of the branch management of git tutorials

What is the use of branching in practice?

You create a branch that belongs to you, others can't see it, others continue to work on the original branch, and you're working on your own branch, and you want to submit it, and then merge it into the original branch once the development is complete, It is safe and does not affect other people's work.

In version fallback, we already know that every commit, git strings them into a timeline, which is a branch of the line. As of now, there is only one time line, in Git, this branch is called the main branch, the Master branch. The head is strictly not pointing to the commit, but pointing to Master,master is pointing to the commit, so the head is pointing to the current branch.
At first, the master branch is a line, andgit uses master to point to the latest commit, and then head to masterto determine the current branch and the commit point of the current branch:

The Master branch moves forward one step at a time, so that as you continue to commit, the master branch line is getting longer:

A,b,c,d represents four commits, each commit, and master moves toward the new submission.

When we create a new branch, such as Dev, Git creates a new pointer called Dev, points to the same commit as Master, and then points the head to dev, which indicates that the current branch is on Dev :

Git creates a branch quickly, because in addition to adding a dev pointer, change the head to point to, the workspace files are not any change!

However, from now on, the workspace modification and submission is for the Dev branch , such as after the new commit, the dev pointer moves forward one step, and the master pointer does not change :

If our work on Dev is done, we can merge dev into master . How does git merge? The simplest way to do this is to directly connect master to the current commit of Dev and complete the merge:

So git merge branch is fast too! Just change the pointer, the work area content is also unchanged!
After you merge the branches, you can even delete the dev branch. Removing the dev branch is to delete the dev pointer and delete it, we have a master branch left:

First, we create the dev branch and then switch to the dev branch:

$ git checkout-'dev'

The git checkout command plus the- b parameter means create and switch , equivalent to the following two commands:

' Dev '

Then, use the GIT branch command to view the current branch:

$ git Branch* Dev  master

The git branch command lists all branches, preceded by an * number in front of the current branch .
Then we can commit normally on the dev branch, such as making a change to Readme.txt, plus a line:

Then submit:

Now that the Dev branch's work is done, we can switch back to the master branch:

After switching back to the master branch, and then looking at a Readme.txt file, the content just added is gone! Because that commit is on the dev branch , the commit point of the master Branch at the moment does not change:

Visible, the Readme.txt on the master branch does not have creating a new branch is quick. This sentence

Creating A new branch is quick submitted by dev at

Now, let's merge the work of the Dev branch onto the master branch:

We are now on the master branch.

The git merge command is used to merge the specified branch into the current branch. After merging, and then looking at the contents of the Readme.txt, you can see that the latest commit with the Dev branch is exactly the same.
Taking note of the fast-forward information above, Git tells us that this merger is a "fast-forward mode", which is to direct master to the current commit of Dev, so the merging is very fast.
Of course, not every merger can be fast-forward, and we'll talk about other ways of merging later.
Once the merge is complete, you can safely delete the dev branch:

After deleting, view branch, only the master branch is left:

Because creating, merging, and deleting branches is fast, git encourages you to use branches to accomplish a task, merge and then delete the branch, which works the same as directly on the master branch, but it is more secure.

(

GIT encourages the use of branching:

View branches: Git branch

Create a branch: Git branch <name>

Switch branches: git checkout <name>

Create + switch branches: git checkout-b <name>

Merge a branch to the current branch: git merge <name>

Delete branch: Git branch-d <name>

)

Resolve Conflicts

prepare a new Feature1 branch and continue our new branch development:



Span style= "FONT-SIZE:15PX; Font-family:courier new,courier; " > Commit on the Feature1 branch:

switch to Master branch:

git also automatically prompts us that the current Master branch is ahead of 1 commits than the remote master branch 。


commit:

Master: & Simple

Feature1:and Simple

In this case, git cannot perform a "quick merge" and can only attempt to merge its own changes, but the merge may conflict, so let's try this:

It's a conflict! Git tells us that there is a conflict with the Readme.txt file and must be resolved manually before committing. Git status can also tell us about conflicting files:

We can view the contents of Readme.txt directly:

Git uses <<<<<<<,=======,>>>>>>> to mark the contents of different branches, we modify the following to save:

Re-submit:

Now, the master branch and the Feature1 branch become the following:

You can also see the merging of branches with the git log with parameters:

Finally, delete the Feature1 branch:

One of the branch management of git tutorials