Git版本控制(5) —— 分支管理策略

在我们的日常工作中，当我们提pr merge到staging(测试)分支的时候，会发生冲突，我们需要在本地解决冲突。gitlab网页会提示我们使用merge指令的时候使用–no–ff参数。这里需要稍微解释一下，no–ff参数是什么意思。默认情况下，Git执行”快进式合并”（fast-farward merge），会直接将stagng分支指向Develop分支。

使用–no–ff参数后，会执行正常合并，在Master分支上生成一个新节点。但是为了保证版本演进的清晰，我们还是希望采用这个用法。merge完成之后，我们检查git log，我们会看到多了一条meger Develop branch into staging的日志。

接下来来介绍两个骚操作：

有时候当我们要切换分支，但是两个分支之间有冲突，这在feature分支版本控制的时候，是经常发生的。比如说，当我从一个分支切回master分支时，如果你的修改还保留在工作区和暂存区（只add，但是没有commit），冲突时常会发生。以前我经常就是直接放弃某个分支的修改（commit + git reset -hard commit-id)， 这是十分愚蠢的做法。git stash 可以很好地帮我们解决这个问题。

git stash: 保存当前的工作进度, 会分别对暂存区和工作区的状态进行保存

git stash save “message…” 这条命令实际上是第一条 git stash 命令的完整版

git stash list : 显示进度列表。此命令显然暗示了git stash 可以多次保存工作进度，并用在恢复时候进行选择。 每个分支的git stash 状态都会保存在这个list里面

git stash pop : 如果不使用任何参数，会恢复最新保存的工作进度，并将恢复的工作进度从存储的工作进度列表中清除。

git stash clear : 删除所有存储的进度