6 分支管理
从其他分支分离出来，创建一个属于自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受。但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库文件的多少。
6.1创建与合并分支
在版本回退里，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即
master
分支。
HEAD
严格来说不是指向提交，而是指向
master
，
master
才是指向提交的，所以，
HEAD
指向的就是当前分支。
一开始的时候，
master
分支是一条线，Git用
master
指向最新的提交，再用
HEAD
指向
master
，就能确定当前分支，以及当前分支的提交点：
每次提交，
master
分支都会向前移动一步，这样，随着你不断提交，
master
分支的线也越来越长。
当我们创建新的分支，例如
dev
时，Git新建了一个指针叫
dev
，指向
master
相同的提交，再把
HEAD
指向
dev
，就表示当前分支在
dev
上：
Git创建一个分支很快，因为除了增加一个
dev
指针，改改
HEAD
的指向，工作区的文件都没有任何变化！
不过，从现在开始，对工作区的修改和提交就是针对
dev
分支了，比如新提交一次后，
dev
指针往前移动一步，而
master
指针不变：
假如我们在
dev
上的工作完成了，就可以把
dev
合并到
master
上。Git怎么合并呢？最简单的方法，就是直接把
master
指向
dev
的当前提交，就完成了合并：
所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完分支后，甚至可以删除
dev
分支。删除
dev
分支就是把
dev
指针给删掉，删掉后，我们就剩下了一条
master
分支：
下面开始实战。
首先，我们创建
dev
分支，然后切换到
dev
分支：
$ git checkout -b dev
Switched to a new branch 'dev'
git checkout
命令加上
-b
参数表示创建并切换，相当于以下两条命令：
$ git branch dev
$ git checkout dev
Switched to branch 'dev' 然后，用
git branch
命令查看当前分支：
$ git branch
* dev
master
git branch
命令会列出所有分支，当前分支前面会标一个
*
号。
然后，我们就可以在
dev
分支上正常提交，比如对
readme.txt
做个修改，加上一行：
Creating a new branch is quick. 然后提交：
$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test
1 file changed, 1 insertion(+) 现在，
dev
分支的工作完成，我们就可以切换回
master
分支：
$ git checkout master
Switched to branch 'master' 切换回
master
分支后，再查看一个
readme.txt
文件，刚才添加的内容不见了！因为那个提交是在
dev
分支上，而
master
分支此刻的提交点并没有变：
现在，我们把
dev
分支的工作成果合并到
master
分支上：
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge
命令用于合并指定分支到当前分支。合并后，再查看
readme.txt
的内容，就可以看到，和
dev
分支的最新提交是完全一样的。
注意到上面的
Fast-forward
信息，Git告诉我们，这次合并是“快进模式”，也就是直接把
master
指向
dev
的当前提交，所以合并速度非常快。
当然，也不是每次合并都能
Fast-forward
，我们后面会讲其他方式的合并。
合并完成后，就可以放心地删除
dev
分支了：
$ git branch -d dev
Deleted branch dev (was b17d20e). 删除后，查看
branch
，就只剩下
master
分支了：
$ git branch
* master 因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在
master
分支上工作效果是一样的，但过程更安全。
6.2解决冲突
创建分支，继续我们的新分支开发：
$ git checkout -b learngitnew
Switched to a new branch 'learngitnew' 修改
readme.txt
最后一行，改为：
aaaaaa 在learngitnew分支上提交：
$ git add readme.txt
$ git commit -m "aaaaa"
[feature1 14096d0] aaaaa
1 file changed, 1 insertion(+), 1 deletion(-) 切换到
master
分支：
$ 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还会自动提示我们当前
master
分支比远程的
master
分支要超前1个提交。在
master
分支上把
readme.txt
文件的最后一行改为：
bbbbb 提交：
$ git add readme.txt
$ git commit -m "bbbbb"
[master 5dc6824] bbbbb
1 file changed, 1 insertion(+), 1 deletion(-) 现在，
master
分支和learngitnew分支各自都分别有新的提交，变成了这样：
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
$ git merge learngitnew
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
readme.txt
文件存在冲突，必须手动解决冲突后再提交。
git status
也可以告诉我们冲突的文件：
$ 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")
(use "git merge --abort" to abort the merge)
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") 我们可以直接查看readme.txt的内容：
<<<<<<< HEAD
bbbbbb
=======
aaaaa
>>>>>>> feature1 Git用
<<<<<<<
，
=======
，
>>>>>>>
标记出不同分支的内容，我们修改如下后保存：
Creating a new branch is quick and simple. 再提交：
$ git add readme.txt
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed 现在，
master
分支和
feature1
分支变成了下图所示：
用带参数的
git log
也可以看到分支的合并情况：
$ git log --graph --pretty=oneline --abbrev-commit
* 8bdf9f3 (HEAD -> master) fixed conflict
|\
| * 611a226 (learngitnew) aaaaaa
* | 6b7d064 bbbbb
|/
* f011ebc dev add readme.txt
* 5e50a6c (origin/master) change xaxaxa
* 268f236 change fafaf
* 52947eb add file.c 6.3分支管理策略
通常，合并分支时，Git会用
Fast forward
模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用
Fast forward
模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下
--no-ff
方式的
git merge
：
首先，仍然创建并切换
dev
分支：
$ git checkout -b dev
Switched to a new branch 'dev' 修改readme.txt文件，并提交一个新的commit：
$ git add readme.txt
$ git commit -m "add merge"
[dev f52c633] add merge
1 file changed, 1 insertion(+) 现在，我们切换回
master
：
$ git checkout master
Switched to branch 'master' 准备合并
dev
分支，请注意
--no-ff
参数，表示禁用
Fast forward
：
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+) 因为本次合并要创建一个新的commit，所以加上
-m
参数，把commit描述写进去。合并后，我们用
git log
看看分支历史：
$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
... 可以看到，不使用
Fast forward
模式，merge后就像这样：
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，
master
分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；那在哪干活呢？干活都在
dev
分支上，也就是说，
dev
分支是不稳定的，到某个时候，比如1.0版本发布时，再把
dev
分支合并到
master
上，在
master
分支发布1.0版本；你和你的小伙伴们每个人都在
dev
分支上干活，每个人都有自己的分支，时不时地往
dev
分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
注意：合并分支时，加上
--no-ff
参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而
fast forward
合并就看不出来曾经做过合并。
6.4bug分支（git stash）
在修复bug时可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支
issue-101
来修复它，但是，当前正在
dev分支
上进行的工作还没有提交：
$ 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 并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
幸好，Git还提供了一个
stash
功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge 现在，用
git status
查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug，假定需要在
master
分支上修复，就从
master
创建临时分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git checkout -b issue-101
Switched to a new branch 'issue-101' 现在修复bug，需要把“aaaaaa”改为“aaaaa”去掉一个a，然后提交：
$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-) 修复完成后，切换到
master
分支，并完成合并，最后删除
issue-101
分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local 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(-) 太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到
dev
分支干活了！
$ git checkout dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working tree clean 工作区是干净的，刚才的工作现场存到哪去了？用
git stash list
命令看看：
$ git stash list
stash@{0}: WIP on dev: f52c633 add merge 工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
一是用
git stash apply
恢复，但是恢复后，stash内容并不删除，你需要用
git stash drop
来删除；
另一种方式是用
git stash pop
，恢复的同时把stash内容也删了：
$ 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} (5d677e2ee266f39ea296182fb2354265b91b3b2a) 再用
git stash list
查看，就看不到任何stash内容了：
$ git stash list 你可以多次stash，恢复的时候，先用
git stash list
查看，然后恢复指定的stash，用命令：
$ git stash apply stash@{0} 另外
在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？有木有更简单的方法？有！
同样的bug，要在dev上修复，我们只需要把
4c805e2 fix bug 101
这个提交所做的修改“复制”到dev分支。注意：我们只想复制
4c805e2 fix bug 101
这个提交所做的修改，并不是把整个master分支merge过来。
为了方便操作，Git专门提供了一个
cherry-pick
命令，让我们能复制一个特定的提交到当前分支：
$ git branch
* dev
master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-) Git自动给dev分支做了一次提交，注意这次提交的commit是
1d4b803
，它并不同于master的
4c805e2
，因为这两个commit只是改动相同，但确实是两个不同的commit。用
git cherry-pick
，我们就不需要在dev分支上手动再把修bug的过程重复一遍。
有些聪明的童鞋会想了，既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？当然可以，不过你仍然需要
git stash
命令保存现场，才能从dev分支切换到master分支。
6.5 Feature分支
软件开发中，总有无穷无尽的新的功能要不断添加进来。添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。
于是准备开发：
$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan' 5分钟后，开发完毕：
$ git add vulcan.py
$ git status
On branch feature-vulcan
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: vulcan.py
$ git commit -m "add feature vulcan"
[feature-vulcan 287773e] add feature vulcan
1 file changed, 2 insertions(+)
create mode 100644 vulcan.py 切回
dev
，准备合并：
$ git checkout dev 一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。
但是！就在此时，接到上级命令，因经费不足，新功能必须取消！虽然白干了，但是这个包含机密资料的分支还是必须就地销毁：
$ git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-vulcan'. 销毁失败。Git友情提醒，
feature-vulcan
分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的
-D
参数。
现在我们强行删除：
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 287773e). 6.6多人协作
多人协作的工作模式通常是这样：
- 首先，可以试图用
git push origin <branch-name>
- 如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull
- 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用
git push origin <branch-name>
如果
git pull
提示
no tracking information
，则说明本地分支和远程分支的链接关系没有创建，用命令
git branch --set-upstream-to <branch-name> origin/<branch-name>
。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
小结
- 查看远程库信息，使用
git remote -v
- 本地新建的分支如果不推送到远程，对其他人就是不可见的；
- 从本地推送分支，使用
git push origin branch-name
git pull
- 在本地创建和远程分支对应的分支，使用
git checkout -b branch-name origin/branch-name
- 建立本地分支和远程分支的关联，使用
git branch --set-upstream branch-name origin/branch-name
- 从远程抓取分支，使用
git pull
6.7 rebase
多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。
每次合并再push后，分支变成了这样：
$ git log --graph --pretty=oneline --abbrev-commit
* d1be385 (HEAD -> master, origin/master) init hello
* e5e69f1 Merge branch 'dev'
|\
| * 57c53ab (origin/dev, dev) fix env conflict
| |\
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
| |/
* | 12a631b merged bug fix 101
|\ \
| * | 4c805e2 fix bug 101
|/ /
* | e1e9c68 merge with no-ff
|\ \
| |/
| * f52c633 add merge
|/
* cf810e4 conflict fixed 总之看上去很乱，有强迫症的童鞋会问：为什么Git的提交历史不能是一条干净的直线？
其实是可以做到的！
Git有一种称为rebase的操作，有人把它翻译成“变基”。
先不要随意展开想象。我们还是从实际问题出发，看看怎么把分叉的提交变成直线。
在和远程分支同步后，我们对
hello.py
这个文件做了两次提交。用
git log
命令看看：
$ git log --graph --pretty=oneline --abbrev-commit
* 582d922 (HEAD -> master) add author
* 8875536 add comment
* d1be385 (origin/master) init hello
* e5e69f1 Merge branch 'dev'
|\
| * 57c53ab (origin/dev, dev) fix env conflict
| |\
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
... 注意到Git用
(HEAD -> master)
和
(origin/master)
标识出当前分支的HEAD和远程origin的位置分别是
582d922 add author
和
d1be385 init hello
，本地分支比远程分支快两个提交。
现在我们尝试推送本地分支：
$ git push origin master
To github.com:michaelliao/learngit.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to '[email protected]:michaelliao/learngit.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details. 很不幸，失败了，这说明有人先于我们推送了远程分支。按照经验，先pull一下：
$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:michaelliao/learngit
d1be385..f005ed4 master -> origin/master
* [new tag] v1.0 -> v1.0
Auto-merging hello.py
Merge made by the 'recursive' strategy.
hello.py | 1 +
1 file changed, 1 insertion(+) 再用
git status
看看状态：
$ git status
On branch master
Your branch is ahead of 'origin/master' by 3 commits.
(use "git push" to publish your local commits)
nothing to commit, working tree clean 加上刚才合并的提交，现在我们本地分支比远程分支超前3个提交。
用
git log
看看：
$ git log --graph --pretty=oneline --abbrev-commit
* e0ea545 (HEAD -> master) Merge branch 'master' of github.com:michaelliao/learngit
|\
| * f005ed4 (origin/master) set exit=1
* | 582d922 add author
* | 8875536 add comment
|/
* d1be385 init hello
... 对强迫症童鞋来说，现在事情有点不对头，提交历史分叉了。如果现在把本地分支push到远程，有没有问题？
有！
什么问题？
不好看！
有没有解决方法？
有！
这个时候，rebase就派上了用场。我们输入命令
git rebase
试试：
$ git rebase
First, rewinding head to replay your work on top of it...
Applying: add comment
Using index info to reconstruct a base tree...
M hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py
Applying: add author
Using index info to reconstruct a base tree...
M hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py 输出了一大堆操作，到底是啥效果？再用
git log
看看：
$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master) add author
* 3611cfe add comment
* f005ed4 (origin/master) set exit=1
* d1be385 init hello
... 原本分叉的提交现在变成一条直线了！这种神奇的操作是怎么实现的？其实原理非常简单。我们注意观察，发现Git把我们本地的提交“挪动”了位置，放到了
f005ed4 (origin/master) set exit=1
之后，这样，整个提交历史就成了一条直线。rebase操作前后，最终的提交内容是一致的，但是，我们本地的commit修改内容已经变化了，它们的修改不再基于
d1be385 init hello
，而是基于
f005ed4 (origin/master) set exit=1
，但最后的提交
7e61ed4
内容是一致的。
这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。
最后，通过push操作把本地分支推送到远程：
Mac:~/learngit michael$ git push origin master
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
To github.com:michaelliao/learngit.git
f005ed4..7e61ed4 master -> master 再用
git log
看看效果：
$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master, origin/master) add author
* 3611cfe add comment
* f005ed4 set exit=1
* d1be385 init hello
...