Git adventures (5): branch and merge in Git (1)

Source: Internet
Author: User
Tags sha1 sha1 hash version control system

BKJIA Editor's note: this is the fifth article in the "Git Adventures" series. The translator LIU Hui translates Git Community Book to explain the branches and mergers in Git and how to deal with conflicts. If you do not know about Git, see Git adventures (1): Git, the first version control system. The following is the text.

Branch and merge

In Git, we can create different branches for debugging, publishing, maintenance, and other work without interfering with each other. Next we will create a test warehouse. Let's take a look at the background of Git branch operations:

$rm -rf test_branch_proj$mkdir test_branch_proj$cd test_branch_proj$git initInitialized empty Git repository in /home/test/test_branch_proj/.git/

In the previous example, we created a readable readme.txt file and submitted it to the repository:

$echo "hello, world" > readme.txt$git add readme.txt$git commit -m "project init"[master (root-commit) 0797f4f] project init 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 readme.txt

Let's take a look at the current status of the working directory (working tree:

$git status# On branch masternothing to commit (working directory clean)

If you pay attention to it, you can see the line "# On branch master", which means that we are currently working On the master branch. When a local warehouse is created, it is generally located on the master branch by default. Let's take a look at how Git stores a branch:

$cd .git$cat HEADref: refs/heads/master

The ". git/HEAD" file stores information about the branch on which we are currently working.

In Git, the branch name information is stored in the ". git/refs/heads" directory:

$ls refs/headsmaster

We can see that there is a file named "master" in the directory. Let's take a look at the content:

$cat refs/heads/master12c875f17c2ed8c37d31b40fb328138a9027f337

We can see that this is a "SHA1 hash string value", that is, an object name. Let's look at what type of object this is:

$cat refs/heads/master | xargs git cat-file -tcommit

Yes, this is a commit. the "master" file contains the "Object Name" recently submitted by the master Branch (master "; based on this "Object Name", we can find the corresponding tree object and binary object (blob ), in short, I can index all objects in this branch by name.

When you run the example in our article on your own machine, you will find that the execution results of the "cat refs/heads/master" command are different from those in the article. In this article, the commit name is "12c875f17c2ed8c37d31b40fb328138a9027f337". As mentioned above, Git generates the "SHA1 hash string value" based on the object content as long as the content is the same, so the corresponding names must be the same. Why is there a different name? Git indeed generates names based on the content, and the same name (SHA1 hash string value) will certainly have the same content, but the commit object (commit) is a bit different from other objects, it has an additional timestamp, so the submitted object generated at different times will not have the same name even if the content is exactly the same.

The following command displays the latest submitted content of the main branch:

$cat refs/heads/master | xargs git cat-file -ptree 0bd1dc15d804534cf25c5cb53260fd03c84fd4b9author liuhui998 1300697913 +0800committer liuhui998 1300697913 +0800 project init

"1300697913 + 0800" is the timestamp ).

View the data (blob) contained in this branch)

$cat refs/heads/master | xargs git cat-file -p | head -n 1 | cut -b6-15 | xargs git cat-file -p100644 blob 4b5fa63702dd96796042e92787f464e28f09f17d readme.txt

When the previous readme.txt

$git cat-file -p 4b5fa63hello, world$cd ..

All right, we are playing in the master branch. Next we want to create our own test branch. The git branch command can be used to create a new branch or view the branches in the current repository. Create a branch named "test": $ git branch test

Let's take a look at the several branches in the current project warehouse:

$git branch* master test

Now we have checked out the "test" branch to the working directory:

$git checkout test

Now let's take a look at the branch on which we are located:

$git branch master* test

Well, now we are in the branch of testbench, so we will modify the "readme.txt" file and submit it to the local warehouse for support:

$echo "In test branch" >> readme.txt$git add readme.txt$git commit -m "test branch modified"[test 7f3c997] test branch modified 1 files changed, 1 insertions(+), 0 deletions(-)

Check the blob contained in the current version:

$git cat-file -p HEAD | head -n 1 | cut -b6-15 | xargs git cat-file -p

Now let's take a look at how Git stores the branch "test" as we did before. Let's see if the file ". git/HEAD" points to the new branch:

$cd .git$cat HEADref: refs/heads/test

Yes, ". git/HEAD" does point to the "test" branch. Let's take a look at the content in the ". git/refs/heads" directory:

$ls refs/headsmastertest

The directory contains a file named "test". Let's take a look at the content:

$cat refs/heads/test7f3c9972577a221b0a30b58981a554aafe10a104

View the latest submitted content of the test Branch:

$cat refs/heads/test | xargs git cat-file -ptree 7fa3bfbeae072063c32621ff08d51f512a3bac53parent b765df9edd4db791530f14c2e107aa40907fed1bauthor liuhui998 1300698655 +0800committer liuhui998 1300698655 +0800 test branch modified

Check the data contained in this branch (blob ):

$cat refs/heads/test | xargs git cat-file -p | head -n 1 | cut -b6-15 | xargs git cat-file -p100644 blob ebe01d6c3c2bbb74e043715310098d8da2baa4bf readme.txt

The contents in the readme.txt file are as follows:

$git cat-file -p ebe01d6hello, worldIn test branchcd ..

Let's go back to the main branch:

$git checkout masterSwitched to branch 'master'$git checkout master$cat readme.txthello, world

If you want to see the differences between the master branch and test branch, you can use the git diff command to view the diff between them:

$git diff testdiff --git a/readme.txt b/readme.txtindex ebe01d6..4b5fa63 100644--- a/readme.txt+++ b/readme.txt@@ -1,2 +1 @@ hello, world-In test branch

The current branch and the test branch have a line less: "-In test branch ".

If the git diff command is executed and the test modification is correct, you can use the git merge command to merge it into the master branch:

$git merge testUpdating b765df9..7f3c997Fast-forward readme.txt | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)

"Updating b765df9 .. 7f3c997 indicates that the content between the "b765df9" and "7f3c997" commit is being updated and merged. "b765df9" indicates that the master branch is located ), "7f3c997" indicates the test branch ).

"Fast-forward" can be understood as a smooth merger without conflict. When readme.txt | 1 + "indicates that a row of this file has been modified," 1 files changed, 1 insertions (+), 0 deletions (-)", this indicates that only one file is modified during the merge, one row of new data is inserted, and zero rows are deleted.

The following figure shows the details of the merge statement readme.txt:

$cat readme.txthello, worldIn test branch

The content is correct. It is the result of the merge of the "master" Branch and the "test" branch. Use "git status" to check whether the current working directory is clean ).

$git status# On branch masternothing to commit (working directory clean)

Okay, now the test branch has ended its mission. If there is no value available, you can use the "git branch-d" command to delete this branch:

$git branch -d testDeleted branch test (was 61ce004).

If the branch you want to delete has not been merged into other branches, you cannot use "git branch-d" to delete it, you need to use "git branch-D" to force deletion.


Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.