Shulou(Shulou.com)06/03 Report--

Preface

The role of the branch in the actual production environment: for example, if you are ready to develop a new feature, but it takes a long time to complete, you write some code on the first day, and if you upload the code immediately, because the code is not finished, an incomplete code base can cause others to fail to work. But if you wait for the code to be written before you submit it, there is a huge risk of losing your daily schedule.

Now that there are branches, such worries are totally unnecessary. Create a branch of your own, others can not see, and continue to work on the original branch, while you work on your own branch, you can submit at any time, until the development is completed, and then merge to the original branch at once, in this way, it is safe and does not affect the work of others.

Almost every version control system supports branching in some form. Using branches means that you can separate from the development mainline and continue to work without affecting the mainline. In many version control systems, this is an expensive process, and it is often necessary to create a complete copy of the source code directory, which takes a long time for large projects.

Some people call the branching model of git a "must kill feature", and it is because of it that git is distinguished from the family of version control systems. What's so special about git? The branches of git are incredibly lightweight, its new operations can be done almost instantly, and switching between different branches is almost as fast. Unlike many other version control systems, git encourages frequent use of branches and merges in workflows, even many times a day.

After you understand the concept of branching and use it skillfully, you will realize why Git is such a powerful and unique tool and really change the way you develop.

For a detailed introduction of git, it is recommended to move to the git official documentation for systematic study!

1) install and initialize the git version library [root@git ~] # yum-y install git [root@git ~] # git-versiongit version 1.8.3.1 [root@localhost ~] # mkdir / git & & cd / git [root@git git] # git init initialize the empty Git version library at / git/.git/ [root@git git] # git config-global user.name admin [root@git git] # git config-global user.email admin@admin.com2), Quickly merge and delete branches [root@localhost git] # echo-e "first line" > README.txt [root@localhost git] # git add README.txt [root@git git] # git commit-m "first submission from master branch" [root@localhost git] # git checkout-b dev# to create a new branch Name is dev And switch to the dev branch # the following operations under the dev branch operation # [root@localhost git] # git branch # to view the current branch situation * the "*" sign before the dev # branch indicates the current Under this branch, master [root@git git] # echo-e "# second Line" > > README.txt [root@git git] # git add README.txt [root@git git] # git commit-m "first submission from dev Branch" [root@git git] # cat README.txt # View the file contents under the dev branch # Line 1 # Line 2 [root@git git] # git checkout master# switch to master Branch # # in the master branch operation # [root@git git] # git branch # ensure that the branch switches successfully dev* master [root@git git] # cat README.txt # View the file content under the master branch # the first line [root@git git] # git merge dev# merges the dev branch with the current (master) branch Adopt the method of quick merge [root@git git] # cat README.txt # View the file content again # Line 1 # Line 2 [root@git git] # git log-graph-pretty=oneline-abbrev-commit # View the submitted log information Make it show on one line * da7e6c8 first commit from dev branch * 78c0b14 first commit from master branch # you can see that the "*" number in front of the submission log is in the same column, which is the characteristic of using fast merge (default) # for a long time, you can't tell, specifically, the submission in that branch # write down the method to close the fast merge later, and compare the two! [root@git git] # git branch-d dev # Delete dev branch (if not under dev branch) 3) resolve branch conflict

In our actual work, we will encounter a problem of branch conflict, that is, when you modify the content of the file under the work branch dev, and then before you submit it to the version library, the content under the master branch has changed. At this time, the content under your dev branch is older than the content under master. In this case, when you merge branches, there will be a concept of branch conflict. An example is as follows:

[root@git git] # mkdir / lzj & & cd / lzj # recreate the directory to test [root@git lzj] # git init # initialization directory [root@git lzj] # echo "aaaa" > readme.txt [root@git lzj] # git add readme.txt [root@git lzj] # git commit-m "commit from master" # upload test files to version [root@git lzj] # git branch # confirm current branch * master [root@git lzj] # cat readme.txt # confirm file content aaaa [root@git lzj] # git checkout-b dev # create dev branch and switch to dev branch [root@git lzj] # echo "bbbb" > > readme.txt [root@git lzj] # git add readme.txt [root@git lzj] # git commit-m "commit form dev" # submit the content of the dev branch to the version library [root@git lzj] # cat readme.txt # View the file content aaaabbbb [root@git lzj] # git checkout master # switch to the master branch [root@git lzj] # cat readme.txt # to view the file content (or the original content) aaaa [root@git Lzj] # echo "cccc" > > readme.txt [root@git lzj] # git add readme.txt [root@git lzj] # git commit-m "alter commit from master" # insert content again and submit [root@git lzj] # cat readme.txt # confirm file content aaaacccc [root@git lzj] # git merge dev # merge dev branch with master branch # return the following Explain that conflicts occur when merging automatically merge readme.txt conflicts (content): merge conflicts in readme.txt automatic merge failure, correct the conflict and then submit the result of the correction. # the next step is to resolve the conflict during the merger # the above error message indicates that the content under the dev branch exists the file of the master branch, but the file of the dev branch is not merged with the file under the master branch, and you can submit it again # in the actual environment, direct submission is not recommended Because there may be something special about the file content [root@git lzj] # vim readme.txt # at this time, the file content is as follows: aaaa > dev [root@git lzj] # cat readme.txt # resubmit aaaccccbbbb [root @ git lzj] # git add readme.txt [root@git lzj] # git commit-m "conflict resolved" # submit again [root@git lzj] # git log-- graph-- pretty=oneline-- abbrev-commit# to view branch merging * 9549c57 conflict resolved |\ | * 336e03c commit from dev* | 26e7e0d alter commit from master | / * e766eaf commit from master4) disable fast merge

As mentioned above, when looking at the submission history of the git version, the branch structure is not so intuitive because the option of fast merge is turned on by default, and here is how to turn off fast merge.

[root@git lzj] # git checkout dev # switch to [root@git lzj] # echo "dddd" > > readme.txt [root@git lzj] # git add readme.txt [root@git lzj] # git commit-m "close Quick merge" # insert data and submit [root@git lzj] # git checkout master # switch master branch [root@] Git lzj] # git merge-- no-ff-m "Branch merge description" dev #-- no-ff "option is to turn off fast merge You need to add the submitted description information [root@git lzj] # git log-- graph-- pretty=oneline-- abbrev-commit # to view the submitted log information and display * 2255433 branch merge instructions on one line |\ | * 5c3d07a closes fast merge * | 9549c57 conflict has been resolved # from here to the top You can see that it was submitted after a branch |\\ | / | * 336e03c commit from dev* | 26e7e0d alter commit from master | / * e766eaf commit from master [root@git lzj] # git branch-d dev # Delete dev branch 5) Bug branch

Developers in the development process, bug as usual, with bug to repair, in git, because the branch is powerful, so you can use a new temporary branch to repair bug, repair, branches merge, and then delete the temporary branch.

When we received a task to modify the bug, we naturally wanted to create a branch to repair it, but in the middle of the ongoing work, it could not be submitted, but we needed to repair the bug immediately. At this time, we can "store" the current workspace through the stash function provided by git, and continue to work after the site is restored later.

1) in the middle of the work, the status of the workspace is as follows: [root@git lzj] # cat readme.txt aaaaccccbbbbdddd [root@git lzj] # echo "eeee" > > readme.txt [root@git lzj] # git status # check the status and you can see that there are modifications but not submitted # changes that have not been temporarily saved in the branch master# for submission: # (use "git add..." Update the content to be submitted) # (use "git checkout--..." Discard workspace changes) # # modifications: readme.txt# modifications have not been added to the submission (using "git add" and / or "git commit-a") 2) hide the workspace at this time [root@git lzj] # git stash # use this command to hide the current workspace [root@git lzj] # git status # View the current workspace again Is the clean state # located in the branch master with no files to submit, clean workspace [root@git lzj] # cat readme.txt # check the contents of the file again Aaaaccccbbbbdddd3) suppose you repair bug [root@git lzj] # git checkout-b dev # on the dev branch to create a dev branch and switch to the dev branch [root@git lzj] # echo "ffff" > > readme.txt [root@git lzj] # git add readme.txt [root@git lzj] # git commit-m "alter from dev" [root@git lzj] # git checkout master # switch to Master branch [root@git lzj] # git merge dev # quickly merge dev branches # there are two recovery methods: # one is to use git stash apply to recover However, after recovery, the stash content is not deleted and needs to be deleted with git stash drop. # another way is to use git stash pop to delete the stash content when restoring. Here I use the second method [root@git lzj] # git stash pop # reply to the contents of the storage [root@git lzj] # cat readme.txt aaaaccccbbbbdddd > Stashed changes# to view the contents of the file and find that there is a branch conflict [root@git lzj] # cat readme.txt aaaaccccbbbbddddffffeeee# delete the garbled code in the file [root@git lzj] # git add readme.txt [root@git lzj] # git commit-m "to resolve the branch conflict. "# resubmit 6) remote branch management

Associate the local version library with github. For simplicity, omit this step!

[root@git ~] # git clone git@github.com:lvzhenjiang-hub/test.git# pulls the data on the github to the local [root@git ~] # git remote add origin git@github.com:lvzhenjiang-hub/test.git [root@git ~] # git remote # to view remotely associated remote hosts Use the "- v" option to view details origin [root@git ~] # git checkout-b dev # create and enter the dev branch [root@git ~] # echo "aaa" > 123.txt [root@git ~] # git add 123.txt [root@git ~] # git commit-m "aaa" [root@git ~] # git push origin dev # to associate the local dev branch with the remote dev. If there is no dev branch in the remote, a new one will be created.

As shown in the figure:

[root@git ~] # git branch-r-d origin/dev # delete the remote dev branch [root@git ~] # git push origin: dev # submit the deleted remote branch to the remote version library

If github is under the dev branch, the following page appears when refreshed again, as shown in the figure:

This is the end of this blog post, thank you for reading-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.