避免合并开发人员功能分支的问题，搞乱主分支的历史

Question

我们最近从SVN迁移 - ＆gt; Git（使用Stash）。在迁移之后，我们已经开始在合并期间看到问题，其中一些开发人员正在搞乱他们的功能分支上的合并。

**Our workflow model:-**

master    1---2----3------------4----5
            | |        |   |    |    | 
            | |        M   |    |    |  
feature1    | a--------b---     |    | 
            |                   M    |
feature2    c-----------------d-------

在上图中可以说developer1有一个功能分支feature1，已经完成了他的更改并合并回来开发。

Developer2有一个分支，它是在developer1的分支之前创建的，但它将会存在很长时间。完成更改后，他会将更改从master转移到其分支中，解决所有冲突，然后重新合并。

问题在于，当developer2将更改合并到他的本地分支时，他通过优先选择自己的文件来解决合并冲突。但是，这实际上是覆盖一些他没有改变的文件。当他创建一个pull请求并合并回master时，他会有效地将developer1的更改回滚到之前的版本。我们可以解决这个问题，因为文件实际上会回滚到先前的提交（SHA）id

问题是，

1. 有没有办法我们可以系统地避免这种情况，即问git 拒绝对master实际更改SHA id的任何更改 回滚。
2. 开发人员获得合并时是否有办法？ 仅针对已更改的文件发生冲突

我的谷歌搜索带我到文章，建议使用--rebase选项进行git pull或更改master分支上的权限，以便它们只允许快进合并。其中任何一个选项都会有所帮助。

Answer 1

欢迎来到git。这是你意识到它不是魔术的地方，合并问题并没有消失，你仍然需要像往常一样合并。

答案是确保开发人员正确合并，世界上没有任何工具会强迫您这样做。这最终是一个人的问题。

我建议对所有推送请求返回原点或合并到主控的强制执行代码审查。其中一项审查将是检查历史记录，看看是否有任何此类覆盖已经发生并进行了适当的谴责。