Git rebase似乎使用了旧版本的文件,从而导致冲突

5sxhfpxr  于 2023-02-17  发布在  Git
关注(0)|答案(1)|浏览(193)

我在Mac上使用GitHub Desktop,将Beanstalk作为远程git仓库服务器。
我有一个项目,有Main、Dev和Dev-phpunit-baseline分支。Main是生产就绪的,Dev是Main的分支,Dev-phpunit-baseline是Dev的分支。我在Dev-phpunit-baseline中单独工作,而我的团队在Dev中工作(不修改任何PHPUnit代码)。我的团队已经将Dev-phpunit-baseline合并到Dev中几次,没有发生任何意外。
我有4个@author属性不正确的文件,我把它们提交到Dev-phpunit-baseline,然后合并到Dev。我修正了属性,提交到Dev-phpunit-baseline,然后合并到Dev以纠正错误。更新后的@author行现在是Dev-phpunit-baseline和Dev分支(以及Main,但那是不相关的)的一部分。
在修正合并之后,我的队友更新了Dev。我想把Dev的修改应用到Dev-phpunit-baseline;由于职责分离,重新定基听起来是合适的。
我 checkout Dev-phpunit-baseline。我从Branch菜单中选择“Rebase current分支”,然后选择Dev。合并冲突窗口出现,显示所有4个文件的原始作者,而不是当前作者。x1c 0d1x
以下是其中一个冲突文件的示例(所有其他文件都类似):

当我 checkout Dev时,这些文件显示了更新后的作者。远程Beanstalk仓库中的两个分支(Dev & Dev-phpunit-baseline)在所有4个文件中显示了更新后的作者。我的本地文件夹中的Dev-phpunit-baseline文件显示了更新后的作者。
我 checkout 了Dev,将有问题的文件复制到一个临时目录, checkout 了Dev-phpunit-baseline,然后将文件从临时目录移动到正确的位置,覆盖了现有的文件。
我 checkout 了Dev,删除了我的本地文件,然后从Beanstalk Origin重新加载它们。仍然是同样的问题。
我删除了我的整个本地仓库文件夹(包括.git文件夹),然后从Beanstalk重新克隆。
这个问题也发生在命令行(所以它不是GitHub桌面的孤立问题)。
这不可能是空格或行尾的问题(参见Github Merge Conflict Despite Identical Lines In FileWhy does git show a conflict between two apparently identical added files?),因为合并冲突显示的是不同的行,而不是相同的行。
以下所有问题本质上都是,“如何修复这个问题?”Git从哪里得到旧版本的文件?为什么Git不能从本地Dev分支中提取正确的文件?我还可以尝试解决这个问题吗?
提前感谢您的任何提示或解决方案。

fafcakar

fafcakar1#

Git是从哪里得到这个文件的旧版本的?
当发生冲突时,可以通过运行命令git ls-files -u在输出中显示未合并的文件来检查事件的低级状态(aka plumbing)。
命令会给出一些行,包括文件模式值、blob id、stage值和文件名。例如:

$ git ls-files -u
100644 ad5e6cfb620eb3086a399bd8dd63f039fa120358 1       .gitignore
100644 73dab4ca75450b2aeb048a5e5632011d95064e58 2       .gitignore
100644 12c32798081dd59a51295275ce1119f5d1662422 3       .gitignore
$

stage值为(详见git-read-tree(1)):

0 Normal, no conflict
1 Common ancestor
2 Current branch (version merged on to)
3 The other branch (version merged from)

因此,给定blob id后,您可以使用git cat-file blob检索相应的文件内容,例如

$ git cat-file blob ad5e6cfb620eb3086a399bd8dd63f039fa120358 > .gitignore.common-base
$

以上是我的脚本git-resolve-conflict-using-kdiff3的操作基础,它会自动执行以上操作,并为您提供为每个冲突文件启动KDiff3的选项。

**而且您真的、真的、真的、真的需要使用一个合适的、完整的三向合并工具来解决与的冲突!**其他任何工具都几乎无用。需要明确的是-一个合适的3-way merge tool是一个显示4个窗格的工具,通常类似于

╔═══════╦═══════╦═══════╗
  ║       ║       ║       ║
  ║   A   ║   B   ║   C   ║
  ║       ║       ║       ║
  ╠═══════╩═══════╩═══════╣
  ║                       ║
  ║         MERGED        ║
  ║                       ║
  ╚═══════════════════════╝

如果你想使用something otherthan kdiff3,也可以,但是这个工具必须支持4个这样的窗格。我不在乎有人付你多少钱让你使用GitHub Desktop或者其他任何只显示那些可怕的嵌入式冲突标记的工具,只有两个版本。你应该立即停止使用它来解决冲突(它可能可以用于其他东西,但 * 不 * 用于合并冲突)。
当然,你也许可以用一把小塑料玩具铲挖你的花园,但你为什么不使用一把大小合适的金属铲呢?

相关问题