GIT branch management: create and merge branches, resolve merge conflicts

Forks are the parallel universes in sci-fi movies, while you're trying to learn Git in front of your computer, and you're trying to learn SVN in another parallel universe.

If the two parallel universes don't interfere with each other, it doesn't matter to you now. At some point, though, the two parallel universes merged, and as a result, you learned both Git and SVN!

What is the use of branches in practice? Suppose you are going to develop a new feature, but it takes two weeks to complete. You wrote 50% of the code in the first week. If you submit it immediately, the incomplete code base will cause others to be unable to work because the code has not been written yet. If you wait for the code to be fully written and then submit it again, there is a huge risk of losing your daily progress.

Now that you have branches, you don't have to be afraid. You created a branch that belongs to you, others can't see it, and you continue to work normally on the original branch, while you work on your own branch, submit it if you want to, and then merge it at one time after the development is completed. On the original branch, in this way, it is both safe and does not affect the work of others.

Other version control systems such as SVN have branch management, but after using them, you will find that these version control systems are slower than a snail to create and switch branches. use.

But Git's branch is different, whether creating, switching and deleting branches, Git can do it in 1 second! Whether your repository is 1 file or 10,000 files.

Create and merge branches

In version rollbacks, you already know that for each commit, Git strings them into a timeline, and this timeline is a branch. As of now, there is only one timeline. In Git, this branch is called the main branch, that is, the masterbranch. HEADStrictly speaking, it does not point to the commit, but points masterto masterthe commit, so it HEADpoints to the current branch.

At the beginning, the masterbranch is a line. Git masterpoints to the latest commit, and then uses the HEADpoint masterto determine the current branch and the commit point of the current branch:

With each commit, the masterbranch moves forward one step, so that as you keep committing, masterthe branch line gets longer and longer:

When we create a new branch, for example dev, Git creates a new pointer called dev, pointing to masterthe same commit, and then HEADpointing to devit, it means the current branch is devon:

You see, Git creates a branch very quickly, because except for adding a devpointer and changing HEADthe pointer, the files in the workspace have not changed!

However, from now on, the modifications and commits to the workspace are for the devbranch. For example, after a new commit, the devpointer moves one step forward, but the masterpointer remains unchanged:

If our devwork on the above is complete, we can devmerge it into the masterabove. How does Git merge? The easiest way is to directly masterpoint devthe current commit to complete the merge:

So Git merging branches is also fast! Just change the pointer, and the content of the workspace will not change!

You can even delete devbranches after you've merged them. Deleting a devbranch is devto delete the pointer. After deletion, we are left with a masterbranch:

It's amazing, can you tell that some commits were made through branches?

Let's start the actual battle.

First, we create devthe branch, then switch to the devbranch:

$ git checkout -b dev
Switched to a new branch 'dev'

git checkoutThe command plus -bparameters means create and switch, which is equivalent to the following two commands:

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

Then, git branchview the current branch with the command:

$ git branch
* dev
  master

git branchThe command will list all branches, the current branch will be marked with a *number.

Then, we can devsubmit normally on the branch, such as making a modification to readme.txt and adding a line:

create new branch dev..

Then submit:

$ git add readme.txt
$ git commit -m "create new branch...."
[dev 45ae9a9] create new branch....
 1 file changed, 1 insertion(+)

Now that the devbranch's work is done, we can switch back to the masterbranch:

$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

After switching back to the masterbranch, look at a readme.txt file again, and the content you just added is gone! Because that commit is on the devbranch, and masterthe commit point of the branch has not changed at the moment:

Now, let dev's merge the branch's work into the masterbranch:

$ git merge dev
Updating 90bc1f7..45ae9a9
Fast-forward
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

git mergeThe command is used to merge the specified branch into the current branch. After merging, check the content of readme.txt again, and you can see that devit is exactly the same as the latest commit of the branch.

Noting the above Fast-forwardinformation, Git tells us that this merge is in "fast-forward mode", that is , the current commit masterpointed to directly dev, so the merge speed is very fast.

Of course, it is not possible to merge every time Fast-forward. We will talk about other ways of merging later.

Once the merge is complete, you can safely delete devthe branch:

$ git branch -d dev
Deleted branch dev (was 45ae9a9).

After deleting, check branch, only the masterbranch is left:

$ git branch
* master

Because creating, merging, and deleting branches is very fast, Git encourages you to use a branch for a task, and then delete the branch after merging, which masteris the same as working directly on the branch, but the process is safer.

summary

Git encourages heavy use of branches:

Check out the branch:git branch

Create a branch:git branch <name>

Switch branches:git checkout <name>

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

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

Delete branch:git branch -d <name>

conflict resolution

Nine times out of ten things don't go as planned in life, and merging branches is often not smooth sailing.

Prepare a new feature1branch to continue our new branch development:

$ git checkout -b feature1
Switched to a new branch 'feature1'

 

Modify the last line of readme.txt to:

create new branch feature1..

 

Commit on feature1branch:

$ git add readme.txt
$ git commit -m "create new branch feature1 first modify"
[feature1 b4309b0] create new branch feature1 first modify
 1 file changed, 1 insertion(+)

Switch to masterbranch:

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Git will also automatically prompt us that the current branch is 1 commit ahead masterof the remote branch.master

Change the last line of the readme.txt file on masterthe branch to:

goback master....

submit:

$ git add readme.txt
$ git commit -m "goback master first modify"
[master 0b56936] goback master first modify
 1 file changed, 1 insertion(+)

Now, the masterbranch and feature1the branch each have their own new commit, which becomes this:

In this case, Git cannot perform a "fast merge", and can only try to merge the respective changes, but this merge may have conflicts, let's try:

$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

Indeed conflict! Git tells us that there is a conflict in the readme.txt file and must be resolved manually before committing. git statusIt is also possible to tell us about conflicting files:

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

We can directly view the content of readme.txt:

test git modify second
study git
three add
four add modify
five add modify
six add modify
seven add modify
eight add modify ...
create new branch dev..
<<<<<<< HEAD
goback master....
=======
create new branch feature1..
>>>>>>> feature1

Git uses <<<<<<<, =======, to >>>>>>>mark the content of different branches, we modify it as follows and save it:

test git modify second
study git
three add
four add modify
five add modify
six add modify
seven add modify
eight add modify ...
create new branch dev..
create new branch feature1..
goback master....

Resubmit:

$ git add readme.txt
$ git commit -m "fixed conflicts"
[master 0f3d64a] fixed conflicts

masterBranches and branches now feature1look like this:

git logYou can also see the merge of branches with parameters :

$ git log --graph --pretty=oneline --abbrev-commit
*   0f3d64a fixed conflicts
|\
| * b4309b0 create new branch feature1 first modify
* | 0b56936 goback master first modify
|/
* 45ae9a9 create new branch....
* 90bc1f7 test name
* c1bdf43 test commit
* dd34c9a no add but commit,because use other parameter
* 4ed30d1 eight modify dify
* b45ca96 eight modify
* 9332d40 seven modify
* 72c6f9b six modify
* f64b5a0 five modify
* de8fd65 four modify
* 83a4b1e three modify
* 01c05cf two modify
* 1acafa7 first modify
* 09c1bba first git

Finally, delete feature1the branch:

$ git branch -d feature1
Deleted branch feature1 (was b4309b0).

summary

When Git can't automatically merge branches, it has to resolve conflicts first. After the conflict is resolved, commit again, and the merge is complete.

Use the git log --graphcommand to see the branch merge diagram.