11.Git分支管理

分支就是科幻电影里面的平行宇宙,当你正在电脑前努力学习Git的时候,另一个你正在另一个平行宇宙里努力学习SVN.
如果两个平行宇宙互不干扰,那对现在的你也没啥影响.不过,在某个时间点,两个平行宇宙合并了.结果,你既学会了Git又学会了SVN!

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。
但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

11.1 创建与合并分支

在学习版本回退部分时，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长， 当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快!就改改指针,工作区内容也不变!
合并完分支后,甚至可以删除dev分支.删除dev分支就是把dev指针给删掉,删掉后,我们就剩下了一条master分支.

真是太神奇了,你看得出来有些提交是通过分支完成的吗?

下面开始实战

1.执行`git checkout`命令创建分支,加上-b参数表示创建并切换分支.
    $ git checkout -b dev
    Switched to a new branch 'dev'

执行`git branch`命令创建分支,执行`git checkout`命令切换分支.
    $ git branch dev
    $ git checkout dev
    Switched to branch 'dev'

执行`git branch`命令会列出所有分支,当前分支前面会标一个*号.
    $ git branch
    * dev
      master

然后,我们就可以在dev分支上正常提交,比如对helloworld.txt做个修改，加上一行：
    nice to meet you !

查看修改后的helloworld.txt
    $ cat helloworld.txt
    helloWorld
    nice to meet you !

# 将所有发生改变的文件添加到暂存区
    $ git add helloworld
    warning: LF will be replaced by CRLF in helloworld.
    The file will have its original line endings in your working directory

# 将暂存区的文件实际保存到仓库的历史纪录
    $ git commit -m'dev branch'
    [dev bb937be] dev branch
     1 file changed, 1 insertion(+)

# 切换到主分支(master)
    $ git checkout master
    Switched to branch 'master'

查看一个helloworld.txt文件,刚才添加的内容不见了！因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:
    $ cat helloworld.txt
    helloWorld

现在,我们把`dev`分支的工作成果合并到`master`分支上:
    $ git merge dev
    Updating 9b32bd4..bb937be
    Fast-forward
     helloworld | 1 +
     1 file changed, 1 insertion(+)
注意到上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快.

git merge命令用于合并指定分支到当前分支.合并后,再查看helloworld.txt的内容,就可以看到,和dev分支的最新提交是完全一样的.
    $ cat helloworld.txt
    helloWorld
    nice to meet you !

$ git branch -d dev``Deleted branch dev (was fec145a).

$ git branch``* master`

11.2 解决冲突

人生不如意之事十之八九,合并分支往往也不是一帆风顺的.
创建新的`feature`分支,继续我们的新分支开发:
$ git checkout -b feature
Switched to a new branch 'feature'

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

`added this line from branch feature 1`

切换到`master`分支:
Administrator@wanghua MINGW64 ~/Desktop/test (feature)
$ git checkout master
Switched to branch 'master'

在master分支,修改helloworld.txt最后一行,改为:
nice to meet you ...
Administrator@wanghua MINGW64 ~/Desktop/test (master)
$ vi helloworld.txt
Administrator@wanghua MINGW64 ~/Desktop/test (master)
$ cat helloworld.txt
helloWorld
nice to meet you , too!

在master分支提交
Administrator@wanghua MINGW64 ~/Desktop/test (master)
$ git add .
Administrator@wanghua MINGW64 ~/Desktop/test (master)
$ git commit -m'master modify'
[master 00701be] master modify
 1 file changed, 1 insertion(+), 1 deletion(-)
现在，`master`分支和`feature1`分支各自都分别有新的提交，变成了这样：

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

`git status`也可以告诉我们冲突的文件：
$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)
Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   helloworld
no changes added to commit (use "git add" and/or "git commit -a")

我们可以直接查看helloworld.txt的内容：
Administrator@wanghua MINGW64 ~/Desktop/test (master|MERGING)
$ cat helloworld
helloWorld
<<<<<<< HEAD
nice to meet you ...
=======
nice to meet you , too!
>>>>>>> feature

11.3 分支策略

在实际开发中,我们应该按照几个基本原则进行分支管理：
首先,`master`分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在`dev`分支上，也就是说，`dev`分支是不稳定的，到某个时候，比如1.0版本发布时，再把`dev`分支合并到`master`上，在`master`分支发布1.0版本；
你和你的小伙伴们每个人都在`dev`分支上干活，每个人都有自己的分支，时不时地往`dev`分支上合并就可以了.
所以，团队合作的分支看起来就像这样：

11.4 bug分支

软件开发中,bug就像家常便饭一样.有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除.
当你正在file2工作时，老板要求你在file1中添加一句话:"nice to meet you ."

`$ git status``# On branch dev``# Changes to be committed:``#   (use "git reset HEAD <file>..." to unstage)``#``#       new file:   hello.py``#``# Changes not staged for commit:``#   (use "git add <file>..." to update what will be committed)``#   (use "git checkout -- <file>..." to discard changes in working directory)``#``#       modified:   readme.txt``#`

`$ git stash``Saved working directory and index state WIP on dev: 6224937 add merge``HEAD is now at 6224937 add merge`

`$ git checkout master``Switched to branch ``'master'``Your branch is ahead of ``'origin/master'` `by 6 commits.``$ git checkout -b issue-101``Switched to a new branch ``'issue-101'`

`$ git add readme.txt ``$ git commit -m ``"fix bug 101"``[issue-101 cc17032] fix bug 101`` ``1 ``file` `changed, 1 insertion(+), 1 deletion(-)`

`$ git checkout master``Switched to branch ``'master'``Your branch is ahead of ``'origin/master'` `by 2 commits.``$ git merge --no-ff -m ``"merged bug fix 101"` `issue-101``Merge made by the ``'recursive'` `strategy.`` ``readme.txt |    2 +-`` ``1 ``file` `changed, 1 insertion(+), 1 deletion(-)``$ git branch -d issue-101``Deleted branch issue-101 (was cc17032).`

`$ git checkout dev``Switched to branch ``'dev'``$ git status``# On branch dev``nothing to commit (working directory clean)`

在file1中添加一句:"nice to meet you ."
Administrator@wanghua MINGW64 ~/Desktop/test (issue-101)
$ vi file1
Administrator@wanghua MINGW64 ~/Desktop/test (issue-101)
$ cat file1
this is file1
nice to meet you .

在issue-101提交
Administrator@wanghua MINGW64 ~/Desktop/test (issue-101)
$ git add file1
Administrator@wanghua MINGW64 ~/Desktop/test (issue-101)
$ git commit -m'issue-101'
[issue-101 cccfbcc] issue-101
 1 file changed, 1 insertion(+)

在issue-101提交,查看文件file1 file2
Administrator@wanghua MINGW64 ~/Desktop/test (issue-101)
$ cat file1
this is file1
nice to meet you .
Administrator@wanghua MINGW64 ~/Desktop/test (issue-101)
$ cat file2
this is file2 .

`$ git stash list``stash@{0}: WIP on dev: 6224937 add merge`

`$ git stash pop``# On branch dev``# Changes to be committed:``#   (use "git reset HEAD <file>..." to unstage)``#``#       new file:   hello.py``#``# Changes not staged for commit:``#   (use "git add <file>..." to update what will be committed)``#   (use "git checkout -- <file>..." to discard changes in working directory)``#``#       modified:   readme.txt``#``Dropped refs``/stash``@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)`

`$ git stash list`

`$ git stash apply stash@{0}`

删除issue-101分支
Administrator@wanghua MINGW64 ~/Desktop/test (master)
$ git branch -d issue-101
Deleted branch issue-101 (was cccfbcc).

太棒了,一分钟搞定file1文件的修改！现在,是时候接着回到dev分支干活了！
Administrator@wanghua MINGW64 ~/Desktop/test (master)
$ git checkout dev
Switched to branch 'dev'
Administrator@wanghua MINGW64 ~/Desktop/test (dev)
$ git status
On branch dev
nothing to commit, working tree clean

工作区是干净的,刚才的工作现场存到哪去了?用git stash list命令看看:
Administrator@wanghua MINGW64 ~/Desktop/test (dev)
$ git stash list
stash@{0}: WIP on dev: c7ae21a file1 file2

工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除,
另一种方式是用git stash pop,恢复的同时把stash内容也删了:
Administrator@wanghua MINGW64 ~/Desktop/test (dev)
$ git stash pop
On branch dev
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
        modified:   file2
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (7f6cace1abb7d2343d3e3b34d5e4ca3da6c417cc)

再用git stash list查看,就看不到任何stash内容了:
Administrator@wanghua MINGW64 ~/Desktop/test (dev)
$ git stash list
stash@{0}: WIP on feature: c6b89e3 file3

你可以多次stash,恢复的时候,先用git stash list查看,然后恢复指定的stash,用命令:
$ git stash apply stash@{0}