【问题标题】:Git merge didn't merge two files only?Git合并不只合并两个文件吗?
【发布时间】:2015-02-09 23:21:50
【问题描述】:

我有 master 分支和 release 分支。发布分支上的最后一次提交在文件中添加了几行,比如 A 和 B。然后这些更改被合并到 master 中(事情发生了)。

后来,其他一些提交被提交给 master,其中一个再次从 A 和 B 中删除了这几行。

现在我将 master 合并到 release 中。一切都很好地合并(除了几个小冲突),但文件 A 和 B 保持不变,存在这几行。

怎么会这样?我可以在合并之前检查发布分支上的提交,然后再次重复它,结果相同。是否有任何命令/开关可以了解合并期间发生的情况?

编辑。 看来我只是做错了什么,但我不明白如何正确地做。我可以很容易地复制这个问题,它似乎正在发生,因为首先在 master 上添加了“bad”行,然后将其删除,并且它们 master 合并到 release 中,其中也存在“bad”行。所以 master 的两次提交都被“歼灭”了,并且释放保持不变,对吧?

那么,我在做什么: 7aee9be 发布时带有“坏”行 84d7ed2 在所有更改之前是 master,比上面更老

现在我签出 84d7ed2,添加“坏”行,提交(在新的测试分支上)。 然后我删除“坏”行,提交。 所以测试分支不再有“坏”行了。 然后我签出 7aee9be 并将测试分支合并到其中。 'bad' 行又回来了,合并提交根本没有任何变化。

【问题讨论】:

  • 类似于stackoverflow.com/a/28512602/6309 的 git diff 将有助于理解为什么那个大块仍然存在。
  • @VonC 我用更多细节更新了这个问题。
  • “添加‘坏’行,提交”是什么意思?您是否将发布分支合并到测试分支中?或者你是否做出与发布分支相同的提交?如果你做后者,那就是你的问题。
  • 也许你的提交历史和你所做的提交的图表可以帮助我们理解你的意思。
  • git log --graph --decorate --oneline $beforeitstarted..$attheproblem 是一个非常有用的概述。

标签: git merge git-merge


【解决方案1】:

这都是关于共同祖先的(3-way merging):

如果在做最后的merge(测试的,没有坏行)来发布(有坏行)时,“坏行”是在发布之后引入的 共同祖先,则合并不会删除它。

自从那个共同的祖先:

  • release 介绍了坏线
  • test 已经引入然后去掉了坏行

在这种情况下,将test 合并到release 中不会删除release 中的坏行:与共同祖先相比,test 引入没有变化,而release做。来自release 的更改被保留。

【讨论】:

  • 我正在与引入坏行的release 的同一修订版合并。
  • @mifki 没关系:测试没有添加任何修改,因为添加了错误的行,然后在测试中删除了。
  • 知道了。有什么方法可以检测到这种情况(除了不再做这种事情)?我只想让release 获得最新的内容,而不管该内容的历史记录。
  • @mifki 肯定:stackoverflow.com/a/2862938/6309(我更喜欢“重置”或“重命名”分支解决方案)
【解决方案2】:

我会从git bisect 开始,找出问题是从哪里开始的。一旦你有了“坏”的提交,检查它并从那个点开始跟踪以找出问题所在。 (因为你的情况确实出了问题)

有几种选择:

  1. 有人做了变基,所以你的提交被覆盖(不太可能,但它仍然是一种选择,因为如果有人做了变基,你很可能会知道它。你的分支可能会变得不可用)
  2. 有人使用强制标志 git push origin master --force 推送“旧”代码,这将导致覆盖旧代码
  3. 当您拉动 (pull = fetch+merge) 时,您遇到了冲突,您通过保留这些行来解决它,因此现在它们将再次被签入。

正如我所建议的,在git bisect 的帮助下尝试弄清楚这一切是什么时候开始的。一旦你弄清楚出了什么问题,解决它就会容易得多。

【讨论】:

  • 对不起,没有。我用更多细节更新了问题。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-06-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多