git管理碰到的问题 -- 什么时候新建 branch

今天同事在merge他的代码（只改动一个文件）到master时碰到了很多文件都有冲突。然后他很纠结，这些改动到底是谁改的，他要怎么解决冲突。由于冲突太多，几乎没法进行code review. 然后他想要强行把 master 上面的代码用他自己的 branch 代码覆盖掉。我说你等等，我先确认下为什么会有这么多冲突。这很明显是版本管理出问题了，因为在一个合理的 git 实践中，一次微小的改动应当不会照成很多文件冲突。然而他已经强行把本地代码 commit 到 master. 还好 master 设置了只接受 pull request merge， 不然后果就是之前正常的改动都被他覆盖掉.

那么为啥说一次 merge 太多冲突说明版本管理的问题呢？慢慢分析。

首先，我们要确定为何会有大量冲突。通过 Source Tree 我们可以看到每个 branch 的提交记录。我查看同事的那个 branch，最后一次提交是5月4号。而 master 在这一天之后总共有接近30次的提交。 也就是说我同事的那个 branch 代码已经滞后了有 30 个版本， 而他自己居然没有发现！更可怕的是他的版本滞后这么多，居然还想都不想要把自己的版本强行 merge 到 master。

这说明项目组对 git 的使用出现了很大的问题。组员对各个版本之间的迭代没有一个直观的认知，以为自己的版本一直是最新的，只要修改，提交就算完事。对于自己的 branch 与 master 还有别的组员的 branch 之间的关系完全忽视。而这还只是表面上的问题，更深层次的问题是没有一个完整的对 git 最佳实践的理解。虽然用 git 用了很久，思维依然提留在svn的时代。用 svn， 每个人从主板本开一个分支，然后开发完一个任务提交自己的版本，下一次从主版本继续拿代码下来再修改再提交。

但是到了 git, 一个合理的实践应该是

1. 基于每个修改项建立分支。
2. 修改项完成后，通过 pull request 来向主版本提交代码
3. 邀请组员复查代码
4. 复查通过，代码 merge 后，分支就应当死亡。

像我同事这种一个分支存活了两三个月，之间主版本迭代几十回， 居然没有发现而且还要继续使用这个分支来提交代码，如果还不发生冲突那只能说明运气太好。

那么既然问题发生了，我们应该怎么来解决呢？当然不能像我同事那样，强行把自己的改动提交到 master，好在有限制，不然他这么强行一提交，别人之前的改动完全被他的提交覆盖，哭都没地方哭。正确的解决办法是他放弃自己的当前改动，放弃之前一直使用的分支（可以删除，理论上一个分支的生命周期到该分支所对应的修改项发布完成之后就应该结束，可以从 repo 中删除了）。从 master 中创建一个仅针对此次修改项的分支，然后在这个新分支上面修改代码。

这样解决的效益就是让他省去了无意义的解决大量冲突的时间，同时也节省了其他组员复查代码的时间，最重要的是保证他的这次微小改动不至于影响其他组员的既有改动。