跟廖雪峰学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(+)

4000



这样就把

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
976e
(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中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！