Git 避免合并开发人员的问题'；s的功能分支来自混乱的主分支'；历史

我们最近从SVN->Git迁移（使用Stash）。迁移之后，我们开始看到合并过程中出现的问题，即一些开发人员在其功能分支上的合并过程中出现了混乱

**Our workflow model:-**

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

在上图中，让我们假设developer1有一个特性分支feature1，已经完成了更改并合并回developer

Developer2有一个分支，它是在developer1的分支之前创建的，但它将存在更长的时间。一旦更改完成，他将更改从master拉入他的分支，解决任何冲突，然后重新合并

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

问题是,

有没有一种方法可以系统地避免这种情况，即让git 拒绝对更改SHA id实际存在的主文件所做的任何更改 倒退

在合并过程中，当开发人员 仅在已更改的文件上发生冲突

---

我的谷歌搜索让我看到了一些文章，其中建议使用--rebase选项进行git拉取，或者更改master branch上的权限，以便它们只允许快进合并。这两个选项都有帮助。

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

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

---

我建议对所有推送请求返回到源或合并到主应用程序进行强制性的代码检查。其中一项审查将是检查历史记录，看看是否发生了任何此类重写，并受到适当的谴责。

告诉您的开发人员停止使用

--ours

或类似的标志，并实际合并更改，而不是仅仅将其吹走。要要求快进合并，需要在合并功能分支之前对其重新设置基础（这仍然需要合并，并且仍然可能会出错）。如果开发人员不理解合并，他们将绝对不理解重新设置基础，并将造成更严重的损害。甚至都不要提到rebase。没有oe在合并时使用——我们的或类似的标志。我们遇到的问题是，我们主要有3个工具来使用git。很多人使用龟甲git，很多人使用GitBash，还有一些人使用eclipse/IntellijIDEs来完成git工作。（a） 开发人员如何设法回滚他们最初没有接触到的文件？（b） “文件回滚到上一个提交id”是什么意思？（c） 为什么拉请求会被批准，如果它搞砸了master？良好的测试覆盖率和在拉请求时在CI中运行的测试将有所帮助，但没有单一的银弹。我完全同意，这就是我正在尝试做的。我要寻找的是一种自动检查历史记录的方法，以检查是否发生了任何重写。我们的一些拉取请求有>100个文件，有时很难手动检查每个文件的历史记录。