1

我们最近从 SVN -> Git (using Stash) 迁移。迁移之后，我们开始在合并期间看到一些开发人员在他们的特性分支上搞砸了合并的问题。

**Our workflow model:-**

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

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

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

问题是，当 developer2 将更改合并到他的本地分支时，他正在通过首选自己的文件来解决合并冲突。但是，这实际上是覆盖 了一些他没有更改的文件。当他创建拉取请求并合并回 master 时，他有效地将 developer1 的更改回滚到以前的版本。我们可以取消它，因为文件实际上回滚到上一个提交 (SHA) id

问题是，

  1. 有没有办法我们可以系统地避免这种情况，即要求 git 拒绝对 master 的任何更改，其中更改 SHA id 实际上是回滚。
  2. 当开发人员仅在他们已更改的文件上发生冲突时，合并期间有没有办法

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

4

1 回答 1

-1

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

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

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

于 2014-08-17T23:29:24.243 回答