[版本控制]——分支管理2

通常，分支合并时，如果可能，git会用fast-forwad模式（快速合并），但是有些快速合并不能成功，但是合并过程中没有发生冲突，这个时候会合并并做一次新的提交

禁用Fast-forward（快速合并）

案例1

master分支和slave分支分别修改了不同的文件并做了提交，这个时候合并slave分支到master分支时，并不会出现冲突，但是禁用了faset-forward提交，且git还会帮忙做一个新的提交已完成合并。此时合并会提示给系统自动提交操作一些说明信息

出现上述提示后，就编辑该文件，在里面写上对系统提交的说明信息，完了保存文件退出就可以正常合并

案例2

在正常合并时，也希望禁止使用 Fast-forward模式，让系统在做完合并的同时对操作进行一次提交

git merge --no-ff -m someinfo branch_name
--no-fff：需要使用这个参数，禁用fast-forward操作
-m someinfo：指定禁用快速合并后，系统自动提交时所需的说明信息

 

Bug分支

什么时候需要禁止快速分支？ 

软件开发的时候，遇到bug是再正常不过的事情了。有了git分支，每个bug都可以通过一个新的临时分支来修复。修复后，合并分支，然后将临时分支删除

• 这里bug修复后，直接合并就会使用快速合并，如果合并完成后删除了临时的bug分支，在操作记录图上看不出来刚才的修复操作记录。所以为了能够对bug修复操作留痕，所以需要禁止快速修复

 保护现场

git 提供了一个 stash 功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作

 恢复现场

• git stash list：查看所有保存的现场
• git stach pop：恢复到栈顶现场（最近一次保存的现场）