Git 分支管理

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。

如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是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 dev命令表示的是“创建dev分支并切换到dev分支”，这其实相当于两条命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

然后，使用git branch查看分支情况：

$ git branch
* dev
  master

这条命令会返回所有的分支，并且在当前的分支上，会有一颗*号。
现在，我们就可以在dev分支上进行正常的提交了，比如我们再在readme.txt文件里加一行内容：

Creating a new branch is quick.

将这个改动提交到版本库中：

$ git add readme.txt
$ git commit -m 'add new branch'
[dev d19f6e8] add new branch
 1 file changed, 2 insertions(+)

OK，现在假设我们在dev分支上的工作已经完成了， 现在我们回到master分支上来：

$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

切换回master分支后，我们可以看到，原先在dev分支上修改过的readme.txt文件并没有产生变化，还是那四句话：

此时的指针状态应该是这样的：

现在，我们需要把dev的工作成果合并到master分支上，我们需要git merge命令：

$ git merge dev
Updating a81ac4f..d19f6e8
Fast-forward
 readme.txt | 2 ++
 1 file changed, 2 insertions(+)

git merge命令用于将指定的分支（dev）合并到当前分支（master）上来，现在我们再看一下readme.txt文件的内容，发现多了一行内容了，已经和dev分支上一模一样了。
注意上面返回的信息中的Fast-forward消息，这意味着这次的合并模式是快进模式，就是将master的指针向前移动到了dev的指针上，这样的合并速度就非常快，当然不是每次都是快进模式的合并，还有其他的合并方式。
合并完成后，假设我们也不再需要dev分支了，我们可以执行命令，将其删除：

$ git branch -d dev
Deleted branch dev (was d19f6e8).

删除后，我们再查看一下版本库中分支的情况：

$ git branch
* master

现在，我们就只剩master这一个分支了。

解决冲突

---

人生不如意之事十之八九，合并分支往往也不是一帆风顺的。

准备新的feature1分支，继续我们的新分支开发：

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

修改readme.txt文件的最后一行内容：

Creating a new branch is quick AND simple.

现在，提交这个分支的修改：

$ git add readme.txt
$ git commit -m 'AND simple'
[feature1 e412abc] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)

好的，完成了feature1上的修改，我们现在回到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)

我们再次修改一下readme.txt文件，将最后一行改为：

Creating a new branch is quick & simple.

提交修改：

$ git add readme.txt
$ git commit -m '& simple'
[master 54d63e2] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)

现在，我们可以思考一下版本的指针状态，现在mater和feature1分支都有了新的提交，所以，应该是这样的：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

$ 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告诉我们在合并时，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里面的内容：

卧槽，居然变成这样了，要怎么办呢？
可以看到，Git使用了<<<<<<<，=======，>>>>>>>标记了不同分支的内容，我们现在将其改成如下内容：

Creating a new branch is quick and simple.

再执行提交操作：

$ git add readme.txt
$ git commit -m 'and simple'
[master f31c8e4] and simple

现在，master分支和feature1分支变成了下面的样子了：

用带参数的git log命令，也可以看到合并的情况：

$ git log --graph --pretty=oneline --abbrev-commit
*   f31c8e4 (HEAD -> master) and simple
|\
| * e412abc (feature1) AND simple
* | 54d63e2 & simple
|/
* d19f6e8 add new branch

最后，删除feature1分支：

$ git branch -d feature1
Deleted branch feature1 (was e412abc).

分支管理策略

---

通常，合并分支时，如果可能，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修改后，进行提交：

$ git add readme.txt
$ git commit -m 'add merge'
[dev 5b54fb4] add merge
 1 file changed, 1 insertion(+)

然后，我们切回master并且准备合并dev分支，这里要使用--no-ff参数：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)
$ git merge --no-ff -m 'merge with no-ff' dev
Merge made by the 'recursive' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

再次使用git log命令，查看一下分支的情况：

$ git log --graph --pretty=oneline --abbrev-commit
*   097a662 (HEAD -> master) merge with no-ff
|\
| * 5b54fb4 (dev) add merge
|/
*   f31c8e4 and simple
...

可以看到，不使用Fast forward模式的情况下，分支情况是这样的：

分支策略

分支的功能很强大，所以我们要遵循以下的几个原则来进行分支管理：

1. master分支应该只用来进行版本的发布，平时不能在上面工作
2. 干活都应该在dev上面，当需要发布稳定版本的时候，将dev合并到master上去
3. 每个开发的小伙伴都应该从dev上分支出自己的版本，然后时不时地与dev进行合并就行了

##