【问题标题】:git rebase. Too many conflicts in areas I would rather have mastergit 变基。我宁愿掌握的领域冲突太多
【发布时间】:2015-10-20 01:05:00
【问题描述】:

我的分支 (B) 继承自 Master(M)。由于时间过去了,M 和 B 已经分道扬镳,但是 B 只修改了树中的一个独占文件夹 (f)。

目标是使 B 与 M 保持同步。我知道它需要解决文件夹 (f) 中的冲突,但是有没有办法简化这一点,以便对于非 f 的所有内容,在重新定位时始终使用 master ?

我正在兜圈子,试图解决我绝对没有修改并希望吸收 M 内容的文件夹的冲突。

提示?

【问题讨论】:

  • 使用 rebase 有帮助吗?或者为什么不将 M 合并到 B 中,这应该会带来除 f 之外的所有 M 更改作为冲突?
  • 您不应该在未更改的文件中出现冲突。难道师父是被别人用力推的?另一种选择是您在 f 之外有一些未跟踪的文件,并且 master 会创建它们。

标签: git rebase


【解决方案1】:

对于不在目录(文件夹)f 中的文件,您想要的相当于 -s theirs。不幸的是,git 首先没有-s theirs,更不用说你可以限制为f

然而,一切都不会丢失,并且通过一些工作(例如 shell 脚本)您可以自动完成大部分工作,因为 git 确实git checkout

在变基时(即,挑选提交以将它们复制到新的基础上),每当 git 因冲突而停止时,您可以简单地 git checkout <rev> -- <path> 处理任何有冲突的 <path>。选择与他们的文件版本相对应的<rev>(由于rebase 反转透视的方式,它只是HEAD 版本;或者您可以使用:2:<path>,尽管我自己没有尝试过)。这等效于使用-s theirs(如果存在),因为它使用相关文件的版本填充索引条目。这意味着您甚至不必git add 结果:它只是解决了冲突。

确保您不要将此应用到您的目录f 中的任何<path>,当然。根据需要手动解决。

一旦完成,恢复 rebase 并让 git 完成它的工作,直到你遇到下一个樱桃挑选冲突。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-01-22
    • 2020-08-23
    • 2013-10-20
    • 2014-03-27
    • 1970-01-01
    • 1970-01-01
    • 2011-05-29
    • 1970-01-01
    相关资源
    最近更新 更多