GIT branch Management

1. What is a branch

using branching means that you can detach from the development main line (that is, out of the main branch) and continue to work without affecting the mainline. This mechanism is very useful in the multiplayer development process, where everyone needs to create a branch of their own, and then merge all the branches after each team has completed their development.

Any version control tool has branch management, but after use you will find that these version control systems create and switch branches slower than snails. Because they need to create a full copy of the source code directory, it can be simply too slow for large projects to tolerate. So the branch function becomes the decoration, everybody does not like to use.

but Git's branches are "different", and git can do it in 1 seconds, whether it's creating, switching, or deleting branches! Whether your repository is 1 files or 10,000 files. Unlike many other version control systems, Git encourages frequent use of branching and merging in the workflow, even if it does not matter many times within a day. Once you understand the concept of branching and use it skillfully, you will realize why Git is such a powerful and unique tool that really changes the way you develop.

How to implement 2.Git branch

We know that git doesn't save file differences or changes, but just a series of file snapshots. This snapshot is called "commit" in Git. Once you've changed the file, or deleted it by mistake, you can recover from a recent commit and continue working instead of losing all of your work for a few months. And we need to do a commit to the file after we've modified the file in Git, so git has to know which version of your commit it is, and use the head pointer in git (its value is a hash string)

The above concept looks bitter and difficult to understand, and we look at it intuitively through the atlas:

$ READMELICENSE$ ‘initial commit of my project‘

when you use Git commit to create a new commit object, Git calculates the checksum of each file for that object, and then saves those directories as tree objects in the Git repository. after that, Git creates a commit object that contains a pointer to the tree object, in addition to the relevant commit information, so that it can reproduce the snapshot's contents when needed in the future.

Now, there are five objects in the Git repository: three BLOB objects that represent the contents of the file snapshot, a tree object that records the contents of the directory tree and the index of each file corresponding to the Blob object, and one that contains the index and other commit information metadata that points to the tree object (the root directory). The Commit object. conceptually, the data and relationships stored by each object in the warehouse look like this:

Make some changes and commit again, and this time the commit object will contain a pointer to the last commit object (the parent object in). After two commits, the warehouse history will look like this:

Now let's talk about branching. A branch in Git is essentially a mutable pointer to a commit object. Git uses master as the default name for the branch (which can also be understood as the main branch). After several commits, you actually have a master branch that points to the last commit object, which automatically moves forward each time it commits. Before we mentioned a pointer called Head, which represents the version of your current commit, this head is exactly a pointer to the local branch you are working on.

Management of 3.Git Branches

Git wants to create a new branch pointer, such as creating a new testing branch, using the git branch command:

$ git branch testing

Running the git branch command simply creates a new branch, but does not automatically switch to that branch, so in this case we still work in the Master branch.

To switch to another branch, you can execute the git checkout command. We now switch to the new testing branch:

$ git checkout testing

HEAD points to the new branch as you convert the branch.

Meaning of the 4.Git branch

What is the specific point of view of git branching through a single experiment? We modified a file test.md and resubmitted it before the master has submitted it under the testing branch.

$ vim test.md$ ‘made a change‘

Now let's go back to the master branch and see:

$ git checkout master

git checkout Master This command has done two things. It moves the HEAD pointer back to the master branch and replaces the files in the working directory with the snapshot content pointed to by the Master branch. in other words, the changes that start now will begin with an older version of this project. Its main function is to temporarily cancel the changes made in the testing branch so that you can develop in another direction.

We make some changes and submit again:

$ vim test.md$ ‘made other changes‘

Now our project submission history has been forked (3-9), because just now we have created a branch, transformed it into something that did some work, and then went back to the original main branch to do something else. These changes are isolated in separate branches: we can switch back and forth in different branches and merge them together when the time is ripe. And all this work, just need to branch and checkout these two commands can be completed.

Because a branch in Git is actually just a file containing the checksum of the object (40 character length SHA-1 string), creating and destroying a branch becomes very inexpensive. To put it bluntly, creating a new branch is simply writing a 41-byte (plus a newline) to a file, and of course it's fast.

5. New and switched branches

Now let's look at a simple example of branching and merging:

1. Develop a Web site.
2. Create a branch to implement a new requirement.
3. Work on this branch.

Suppose at this point, you suddenly receive a phone call saying that there is a serious bug that needs urgent repair, then you can do it in the following way:

1. Return to the branch that was previously published on the production server.
2. Establish a new branch for this emergency repair and fix the problem in it.
3. After testing, go back to the branch where the production server is located, merge the patch branches in, and then push to the production server.
4. Switch to the branch that previously implemented the new requirement and continue working.
   First, we assume that you are working happily in a project and have submitted several updates:

Now we have a new demand for question1. We created a new branch to solve the question iss53

toanew"iss53"

Run git checkout and add the-b parameter to indicate the following command:

$ git branch iss53$ git checkout iss53

Then you start to develop new features, and after committing, the ISS53 branch pointer will also move forward as it is the current branch (in other words, the current HEAD pointer is pointing to ISS53)

$ BaseDaoImpl.java$ ‘added a new footer [issue 53]‘

Now you've got the urgent bug that needs to be repaired right away. With Git, we don't need to publish both the patch and the changes made in the iss53, and we don't need to take the time to restore those changes before creating and releasing the patch to the server. The only thing you need to do is switch back to the master branch and then modify the bug and republish.

But before you do, keep an eye out for your staging area or working directory of changes that have not yet been committed and will conflict with the branch you are about to check out to prevent Git from switching branches for you. It 's best to keep a clean working area when switching branches.

$ git checkout masterSwitched"master"

the content in your working directory is exactly the same as you did before you solved the problem #53, and you can focus on fixing the bug urgently. This is worth remembering: Git restores the contents of the working directory to a snapshot of the Commit object it points to when it checks out a branch. It automatically adds, deletes, and modifies files to ensure that the contents of the catalog are exactly the same as when you submitted them.

Next, you need to make an emergency fix. We created an Emergency Repair branch hotfix to work until it was done:

-b‘hotfix‘tonew"hotfix"$ vim index.-a-m‘fixed the broken email address‘[hotfix]: created 3a0874c: "fixed the broken email address" 1 files changed, 0 insertions(+), 1 deletions(-)

After testing, make sure the patch is successful, then go back to the master branch and merge it in, then publish it to the production server. Use the git merge command to merge:

g ITCheCkouTmasTeR Git merge Hotfix
Updating f42c576. 3a0874c
Fast forward
README | 1-
1 files changed, 0 insertions (+), 1 deletions (-)

Note that a "Fast forward" prompt appears when merging. since the commit object where the current master branch is located is directly upstream of the hotfix branch to be merged, Git simply shifts the master branch pointer directly to the right. in other words, if you go down one branch and you reach another, Git will simply move the pointer to the right as it merges the two, because the single-line history branch does not have any differences to resolve, so the merge process can be called Fast Forward Forward).

Now that the latest modification is in the Commit object pointed to by the current Master branch, it can be deployed to the production server.

After that super-important bug fix release, you want to go back to the job before being interrupted. Since the current hotfix branch and master all point to the same commit object, hotfix has completed its historical mission and can be deleted. Use the-d option of Git branch to perform the delete operation:

-d hotfixDeleted branch hotfix (3a0874c).

Now go back to work on the #53 repair branch that was not completed previously (Figure 3-15):

$ git checkout iss53Switched"iss53"$ vim index.html$ ‘finished the new footer [issue 53]‘[iss53]:ad82d7a:"finished the new footer [issue 53]"110 deletions(-)

Don't worry, the changes to the hotfix branch have not yet been included in the iss53. If you do need to include this patch, you can merge the Master branch into iss53 with git merge master, or wait for iss53 to complete before merging the updates from the ISS53 branch into master.

6. Merging of branches

After the problem #53 related work is complete, you can merge back to the Master branch. The actual operation is similar to the previous Merge hotfix branch, just go back to the master branch and run the git merge command to specify the branch to merge in:

merge iss53Merge made by recursive. README |    1 + 1 files changed, 1 insertions(+), 0 deletions(-)

Note that the underlying implementation of this merge operation differs from the previous hotfix incorporation method. Because this time your development history is branching out from earlier places. Because the Commit object (C4) that the current master branch points to is not the direct ancestor of the ISS53 branch, Git has to do some extra processing. in this case, Git uses the end of the two branches (C4 and C5) and their common ancestor (C2) to perform a simple three-party merge calculation. Figure 3-16 shows the three commit objects that Git uses to merge with a red box:

This time, Git does not simply move the branch pointer right, but instead makes a new snapshot of the three-party merge and automatically creates a commit object (C6) that points to it. This commit object is very special, it has two ancestors (C4 and C5).

Since the results of the previous work have been merged into Master, then iss53 is useless. You can remove it from this:

-d iss53

Reference:
Http://www.open-open.com/lib/view/open1328069889514.html

GIT branch Management