GIT 分支管理：分支管理策略、Bug分支、Feature分支

通常，合并分支时，如果可能，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 commit readme.txt -m "branch manager"
[dev 4c49945] branch manager
1 file changed, 1 insertion(+)

现在，我们切换回

master

：

$ git checkout master
Switched to branch 'master'

准备合并

dev

分支，请注意

--no-ff

参数，表示禁用

Fast forward

：

$ git merge --no-ff -m "merger 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
*   7fbc277 merger with no-ff
|\
| * 4c49945 branch manager
|/
*   0f3d64a fixed conflicts
|\
| * b4309b0 create new branch feature1 first modify
* | 0b56936 goback master first modify
|/
* 45ae9a9 create new branch....
* 90bc1f7 test name
.......

可以看到，不使用

Fast forward

模式，merge后就像这样：

分支策略

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

首先，

master

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

那在哪干活呢？干活都在

dev

分支上，也就是说，

dev

分支是不稳定的，到某个时候，比如1.0版本发布时，再把

dev

分支合并到

master

上，在

master

分支发布1.0版本；

你和你的小伙伴们每个人都在

dev

分支上干活，每个人都有自己的分支，时不时地往

dev

分支上合并就可以了。

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

小结

Git分支十分强大，在团队开发中应该充分应用。

合并分支时，加上

--no-ff

参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而

fast forward

合并就看不出来曾经做过合并。

Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你接到一个修复一个代号001的bug的任务时，很自然地，你想创建一个分支

bug-001

来修复它，但是，等等，当前正在

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")

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个

stash

功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

$ git stash
Saved working directory and index state WIP on dev: e980635 dev
HEAD is now at e980635 dev

现在，用

git status

查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug，假定需要在

master

分支上修复，就从

master

创建临时分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 9 commits.
(use "git push" to publish your local commits)

$ git checkout -b bug-001
Switched to a new branch 'bug-001'

现在修复bug，需要把“git branch manager....”改为“git branch manager....modify”，然后提交：

$ git add readme.txt
$ git commit -m "bug modify"
[bug-001 3b8d00c] bug modify
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 9 commits.
(use "git push" to publish your local commits)
$ git merge --no-ff -m "merge bug fix 001" bug-001
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 directory clean

工作区是干净的，刚才的工作现场存到哪去了？用

git stash list

命令看看：

$ git stash list
stash@{0}: WIP on dev: e980635 dev

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用

git stash apply

恢复，但是恢复后，stash内容并不删除，你需要用

git stash drop

来删除；

另一种方式是用

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} (9bfeed878d4c504cf12c67a6965db13506567b4a)

再用

git stash list

查看，就看不到任何stash内容了：

$ git stash list

你可以多次stash，恢复的时候，先用

git stash list

查看，然后恢复指定的stash，用命令：

$ git stash apply stash@{0}

小结

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场

git stash

一下，然后去修复bug，修复后，再

git stash pop

，回到工作现场。

Feature分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。

于是准备开发：

$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan'

5分钟后，开发完毕：

$ git add readme.txt
$ git status
On branch feature-vulcan
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

modified:   readme.txt

$ git commit -m "add feature-vulcan"
[feature-vulcan 939d622] add feature-vulcan
1 file changed, 4 insertions(+), 2 deletions(-)

切回

dev

，准备合并：

$ git checkout dev
Switched to branch '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

分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用命令

git branch -D feature-vulcan

。

现在我们强行删除：

$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 939d622).

小结

开发一个新feature，最好新建一个分支；

如果要丢弃一个没有被合并过的分支，可以通过

git branch -D <name>

强行删除。