跟廖雪峰学Git 三 —— 分支管理

一、分支的创建与合并

Git 的分支功能十分强大，并且 Git 十分鼓励你使用分支。这样既安全，又能保质保量完成工作。

创建分支之前看一下 readme.txt 文档中的内容：

创建分支

$ 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 命令会列出当前所有分支，并且你当前所在哪个分支，哪个分支前面会有一个 * 号。

修改 readme.txt 文档，新增：

分支练习 branch test

然后 add commit ，提交到仓库。

然后回到 master 主分支：

$ git checkout master
Switched to branch 'master'

这时，再打开 readme.txt 文档：

咦？新增的内容哪去了？

聪明的你一定知道，新增的内容在 dev 分支中呢。那怎么把它合并过来呢？

$ git merge dev
Updating 5fa66d6..822955b
Fast-forward
 readme.txt | 2 ++
 1 file changed, 2 insertions(+)

这样就把 dev 分支中新增的内容合并过来了，并且可以看到，Git 打印出本次的合并方式信息， Fast-forward 信息。这表示本次合并是“快进模式”，也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。

当然，也不是每次合并都能 Fast-forward ，我们后面会讲其他方式的合并。

合并完之后，就可以把 dev 分支删除了。

这样的做法，既对主分支安全，又不耽误工作进度。

• 查看分支：git branch

• 创建分支：git branch

• 切换分支：git checkout

• 创建+切换分支：git checkout -b

• 合并某分支到当前分支：git merge

• 删除分支：git branch -d

二、解决冲突

合并分支的时候，肯定不能每次都是快速合并。一定会有冲突出现的时候。那在 Git 中出现冲突时，怎么解决冲突呢？

先创建一个 other 分支：

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

$ git branch
  master
* other

然后再 other 分支中修改 readme.txt 文档：

然后提交：

$ git add .
$ git commit -m "other branch"
[other 4975a06] other branch
 1 file changed, 2 insertions(+)

回到 master 主分支，修改主分支下 readme.txt 文档：

提交：

$ git add .
$ git commit -m "master branch"
[master bf1e782] master branch
 1 file changed, 2 insertions(+)

这时候， master 和 other 分支中都对 readme.txt 文档进行了修改，并且修改内容不相同。那次是合并分支的话，就一定会有冲突发生：

$ git merge other
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
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用 <<<<<<< ， ======= ， >>>>>>> 标记出不同分支的内容。

我们把冲突修改好后保存，然后提交：

$ git add .
$ git commit -m "resolve conflict"
[master 2d51e2f] resolve conflict

再查看下此时仓库的状态：

$ git status
On branch master
nothing to commit, working tree clean

也可以用 git log 查看当前仓库的分支情况：

$ git log
commit 2d51e2fdf0acbd7ba3c49cbd5cfc0bb498b1dc66 (HEAD -> master)
Merge: bf1e782 4975a06
Author: gink <wang_gk@foxmail.com>
Date:   Fri Dec 1 16:52:39 2017 +0800

    resolve conflict

commit bf1e782ec5a13e6418c66d369266878c6ed8f266
Author: gink <wang_gk@foxmail.com>
Date:   Fri Dec 1 16:48:45 2017 +0800

    master branch

commit 4975a06fa32408713c3bd51daef9a0173b315b88 (other)
Author: gink <wang_gk@foxmail.com>
Date:   Fri Dec 1 16:45:53 2017 +0800

    other branch

commit 822955ba048e9e916f002b60145090c26ecf49d0
Author: gink <wang_gk@foxmail.com>
Date:   Fri Dec 1 15:51:59 2017 +0800

最后，删除 other 分支。

$ git branch -d other
Deleted branch other (was 4975a06).

三、分支管理策略

实际开发中，我们应该按照几个基本原则进行分支管理：

• 首先， master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

• 干活都在 dev 分支上，也就是说， dev 分支是不稳定的，到某个时候，比如1.0版本发布时，再把 dev 分支合并到 master 上，在 master 分支发布1.0版本； 你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上 --no-ff 参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而 fast forward 合并就看不出来曾经做过合并。

四、Bug 分支

开发软件时，肯定少不了与 bug 打交道。在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

加入此时你在 dev 分支上进行开发，突然接到任务要修复一个bug。之前我们介绍过 Git 强大的分支管理，你一定印象深刻。所以此时你一定想要建立一个 issue-1 分支专门修复 bug。但你在 dev 分支上还有未提交的工作，并且此时你还不想提交。这时应该怎么办呢？

$ git status
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:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

Git 有一个 stash 功能，可以把此时的工作现场隐藏起来。
$ git stash
Saved working directory and index state WIP on dev: 2d51e2f resolve conflict

$ git status
On branch dev
nothing to commit, working tree clean

这时，再查看工作区，发现是干净的。

现在你可以放心地去解决bug了。

首先你需要确定你在哪个分支上解决bug，假如你在 master 分支上去修复。那就要在 master 分支上建立临时分支：

$ git checkout master
Switched to branch 'master'

$ git checkout -b issue-1
Switched to a new branch 'issue-1'

现在修复bug，在 readme.txt 原有文档最后添加一句：

提交到仓库：

$ git add .
$ git commit -m "解决冲突"
[issue-1 d911d5a] 解决冲突
 1 file changed, 1 insertion(+)

修复完bug 后，回到 master 分支，完成合并，并删除 issue-1 分支：

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff -m "merged bug fix 101" issue-1
Merge made by the 'recursive' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

这时，可以回到 dev 分支继续干活了。

使用命令 git stash list 命令查看暂存的工作现场。

然后恢复工作现场有两种方式：

1是 git stash apply ,但是恢复后，stash内容并不删除，你需要用 git stash drop 来删除；

2是 git stash pop ,恢复的同时把stash内容也删了：

$ 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:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (12eb516e441b9e596c720ea88075b298e4290c4e)

到此，建立 bug 分支解决 bug 的操作就完结了。

五、Feature分支

除了 bug，平时的开发工作中也不免要往项目中添加新功能。

添加新功能时，也要建立一个新分支，避免把主分支搞混乱。通常是建立一个 feature 分支，在上面开发，完成后，合并，最后，删除该 feature 分支。

六、多人协作

当你从远程仓库克隆时，实际上Git自动把本地的 master 分支和远程的 master 分支对应起来了，并且，远程仓库的默认名称是 origin 。

要查看远程库的信息，用 git remote ：

$ git remote
origin

或者，用 git remote -v 显示更详细的信息：

$ git remote -v
origin  git@github.com:michaelliao/learngit.git (fetch)
origin  git@github.com:michaelliao/learngit.git (push)

推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

$ git push origin master

如果要推送其他分支，比如 dev ，就改成：

$ git push origin dev

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

• master 分支是主分支，因此要时刻与远程同步；

• dev 分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！