前言
一、Git的分支管理策略
1.1 Fast forward 模式和--no-ff 模式
通常合并分支时，如果可能，Git 会采用 Fast forward 模式。还记得如果我们采用 Fastforward 模式之后，形成的合并结果是什么呢？回顾一下图示说明：
在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的还是正常提交的。
但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态为：图示说明：
那么这就不是 Fast forward 模式了，这样的好处是，从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分支，但依旧能看到 master 其实是由其他分支合并得到。代码示例：hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit* 2976afc (HEAD -> master) merge ReadMe|\| * c594fd1 modify ReadMe* | c10f6d0 modify ReadMe|/Git 支持我们强制禁用 Fast forward 模式，那么就会在 merge 时生成一个新的 commit ，这样，从分支历史上就可以看出分支信息。
下⾯我们实战⼀下 --no-ff 方式的 git merge 。
步骤一： 首先，创建新的分支 dev2 ，并切换至新的分支:代码示例：hyb@139-159-150-152:~/gitcode$ git checkout -b dev2 #切换到分支dev2Switched to a new branch 'dev2'
步骤二：修改 ReadMe 文件，并提交一个新的 commit :代码示例：hyb@139-159-150-152:~/gitcode$ cat ReadMehello bithello githello worldhello version1hello version2hello version3write bbb for new brancha,b,c,d #修改文件信息hyb@139-159-150-152:~/gitcode$ git add .hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"[dev2 41b082f] modify ReadMe1 file changed, 1 insertion(+)
步骤三：切回 master 分支，通过开始--no-ff 方式合并
代码示例：
hyb@139-159-150-152:~/gitcode$ git checkout masterSwitched to branch 'master'hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m "merge with no-ff" dev2Merge made by the 'recursive' strategy.ReadMe | 1 +1 file changed, 1 insertion(+)hyb@139-159-150-152:~/gitcode$ cat ReadMehello bithello githello worldhello version1hello version2hello version3write bbb for new brancha,b,c,d请 注意 --no-ff 参数，表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建一个新的 commit ，所以加上 -m 参数，把描述写进去。
步骤四：合并后，查看分支历史
代码示例：
hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit* 5bd16b4 (HEAD -> master) merge with no-ff|\| * 41b082f (dev2) modify ReadMe|/可以看到，不使用 Fast forward 模式，merge后就像这样：图示示例：
总结：
所以在合并分支时，加上 --no-ff 参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而 fast forward 合并就看不出来曾经做过合并。
1.2 企业分支管理策略
在实际开发中，我们应该按照几个 基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪⼲活呢？
干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。图示示例：所以，团队合作的分支看起来就像这样：
二、bug分支
假如我们现在正在 dev2 分支上进行开发，开发到一半，突然发现 master 分支上面有 bug，需要解决。在Git中，每个 bug 都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
可现在 dev2 的代码在工作区中开发了一半，还无法提交，怎么办？代码示例：hyb@139-159-150-152:~/gitcode$ git branch* dev2masterhyb@139-159-150-152:~/gitcode$ cat ReadMehello bithello githello worldhello version1hello version2hello version3write bbb for new brancha,b,c,di am coding ... #dev2 的代码在工作区中开发了一半hyb@139-159-150-152:~/gitcode$ git statusOn branch dev2Changes not staged for commit:(use "git add <file>..." to update what will be committed)(use "git restore <file>..." to discard changes in working directory)modified: ReadMeno changes added to commit (use "git add" and/or "git commit -a")
Git 提供了 git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。代码示例：hyb@139-159-150-152:~/gitcode$ git stashSaved working directory and index state WIP on dev2: 41b082f modify ReadMehyb@139-159-150-152:~/gitcode$ git statusOn branch dev2nothing to commit, working tree clean用 git status 查看工作区，就是干净的（除非有没有被 Git 管理的文件），因此可以放心地创建分支来修复bug。
储藏 dev2 工作区之后，由于我们要基于master分支修复 bug，所以需要切回 master 分支，再新建临时分支来修复 bug。代码示例：hyb@139-159-150-152:~/gitcode$ git checkout master # 切回master分支Switched to branch 'master'hyb@139-159-150-152:~/gitcode$ git checkout -b fix_bug # 新建并切换到 fix_bug 分支Switched to a new branch 'fix_bug'hyb@139-159-150-152:~/gitcode$ vim ReadMehyb@139-159-150-152:~/gitcode$ cat ReadMehello bithello githello worldhello version1hello version2hello version3write bbb for new brancha,b,c,d,e # 修复bug--忘记写ehyb@139-159-150-152:~/gitcode$ git add ReadMe # 重新add，commithyb@139-159-150-152:~/gitcode$ git commit -m"fix bug"[fix_bug 4bbc0c4] fix bug1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后，切换到 master 分支，并完成合并，最后删除 fix_bug 分支：代码示例：hyb@139-159-150-152:~/gitcode$ git checkout masterSwitched to branch 'master'hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m"merge fix_bug branch" fix_buMerge made by the 'recursive' strategy.ReadMe | 2 +-1 file changed, 1 insertion(+), 1 deletion(-)hyb@139-159-150-152:~/gitcode$ cat ReadMehello bithello githello worldhello version1hello version2hello version3write bbb for new brancha,b,c,d,ehyb@139-159-150-152:~/gitcode$ git branch -d fix_bugDeleted branch fix_bug (was 4bbc0c4).
至此，bug 的修复工作已经做完了，我们还要继续回到 dev2 分支进行开发。切换回 dev2 分支：代码示例：hyb@139-159-150-152:~/gitcode$ git checkout dev2Switched to branch 'dev2'hyb@139-159-150-152:~/gitcode$ git statusOn branch dev2nothing to commit, working tree clean
工作区是干净的，刚才的工作现场存到哪去了？
用 git stash list 命令看看：
代码示例：
hyb@139-159-150-152:~/gitcode$ git stash liststash@{0}: WIP on dev2: 41b082f modify ReadMe
⼯作现场还在，Git 把 stash 内容存在某个地方了，但是需要恢复⼀下，如何恢复现场呢？我们可以使用 git stash pop 命令，恢复的同时会把 stash 也删了，代码示例：hyb@139-159-150-152:~/gitcode$ git stash popOn branch dev2Changes not staged for commit:(use "git add <file>..." to update what will be committed)(use "git restore <file>..." to discard changes in working directory)modified: ReadMeno changes added to commit (use "git add" and/or "git commit -a")Dropped refs/stash@{0} (4f873250b3503687b5efd26196776aee7e3724c2)
再次查看的时候，我们已经发现已经没有现场可以恢复了代码示例：hyb@139-159-150-152:~/gitcode$ git stash listhyb@139-159-150-152:~/gitcode$
另外，恢复现场也可以采用 git stash apply 恢复，但是恢复后，stash内容并不删除，你需要 用 git stash drop 来删除；你可以多次stash，恢复的时候，先用 git stash list 查看，然后恢复指定的stash，用命令git stash apply stash@{0} ,这部分请同学们自行使用。
恢复完代码之后我们便可以继续完成开发，开发完成后便可以进行提交：代码例如：hyb@139-159-150-152:~/gitcode$ cat ReadMehello bithello githello worldhello version1hello version2hello version3write bbb for new brancha,b,c,di am coding ... Done!hyb@139-159-150-152:~/gitcode$ git add .hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"[dev2 ed0916d] modify ReadMe1 file changed, 1 insertion(+)
但我们注意到了，修复 bug 的内容，并没有在 dev2 上显示。 此时的状态图为：
Master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们在 dev2 中当然看不见修复 bug 的相关代码。
我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是 有一定风险的。是因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。我们无法保证对于冲突问题可以正确地一次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。此时的状态图为：
解决这个问题的⼀个好的建议就是：最好在自己的分支上合并下 master ，再让 master 去合并dev ，这样做的目的是有冲突可以在本地分支解决并进行测试，而不影响 master 。此时的状态图为：第一步：
第二步：
注意：对应的实操演示如下，要说明的是，以下演示的merge操作，没有使用 --no-ff ，但上述的图示是禁用 Fast forward 了模式后得出的，主要是为了方便解释问题。
代码示例：
# dev 合并 masterhyb@139-159-150-152:~/gitcode$ git branch* dev2masterhyb@139-159-150-152:~/gitcode$ git merge masterAuto-merging ReadMeCONFLICT (content): Merge conflict in ReadMeAutomatic merge failed; fix conflicts and then commit the result.# 发⽣冲突hyb@139-159-150-152:~/gitcode$ cat ReadMehello bithello githello worldhello version1hello version2hello version3write bbb for new branch<<<<<<< HEADa,b,c,di am coding ... Done!=======a,b,c,d,e>>>>>>> master# 解决冲突并重新提交hyb@139-159-150-152:~/gitcode$ vim ReadMehyb@139-159-150-152:~/gitcode$ cat ReadMehello bithello githello worldhello version1hello version2hello version3write bbb for new brancha,b,c,d,ei am coding ... Done!hyb@139-159-150-152:~/gitcode$ git add .hyb@139-159-150-152:~/gitcode$ git commit -m"merge master"[dev2 447d29f] merge masterhyb@139-159-150-152:~/gitcode$ git statusOn branch dev2nothing to commit, working tree clean# 切回masterhyb@139-159-150-152:~/gitcode$ git checkout masterSwitched to branch 'master'# master 合并 dev2---⽆需解决冲突！！hyb@139-159-150-152:~/gitcode$ git merge dev2Updating 193421f..447d29fFast-forwardReadMe | 1 +1 file changed, 1 insertion(+)hyb@139-159-150-152:~/gitcode$ git statusOn branch masternothing to commit, working tree clean# 删除 dev2 分⽀hyb@139-159-150-152:~/gitcode$ git branch -d dev2Deleted branch dev2 (was 447d29f).
三、删除临时分支
软件开发中，总有⽆穷⽆尽的新的功能要不断添加进来。添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分⽀搞乱了，所以，每添加⼀个新功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，合并，最后，删除该 feature 分⽀。
可是，如果我们今天正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功能的开发。虽然⽩⼲了，但是这个 feature 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。演⽰如下：# 新增并切换到 dev3 分支hyb@139-159-150-152:~/gitcode$ git checkout -b dev3Switched to a new branch 'dev3'# 开始开发新功能并提交hyb@139-159-150-152:~/gitcode$ vim ReadMehyb@139-159-150-152:~/gitcode$ cat ReadMehello bithello githello worldhello version1hello version2hello version3write bbb for new brancha,b,c,d,ei am coding ... Done!i am writing new features ...hyb@139-159-150-152:~/gitcode$ git add .hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe for new features"[dev3 cd2f149] modify ReadMe for new features1 file changed, 1 insertion(+)# 此时新功能叫停# 切回master准备删除dev3hyb@139-159-150-152:~/gitcode$ git checkout masterSwitched to branch 'master'# 常规删除dev3分支时失败hyb@139-159-150-152:~/gitcode$ git branch -d dev3error: The branch 'dev3' is not fully merged.If you are sure you want to delete it, run 'git branch -D dev3'.
直接使用传统的删除分支的方法不行，按照提示，有了如下方式:代码示例：hyb@139-159-150-152:~/gitcode$ git branch -D dev3Deleted branch dev3 (was cd2f149).hyb@139-159-150-152:~/gitcode$ git branch* master
四、总结
gitee分支的作用：
分支在实际中有什么用呢?假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。并且Git无论创建、切换和删除分支，Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。
总结
423
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
