将fork更新为上游常规

Question

我有一个非常庞大且积极开发项目的分支。通常我每2个月更新一次上游，但这个过程非常痛苦 - 需要一周，工作停止，合并后会出现许多错误。 我只是尝试了git rebase，但是每次提交都会产生很多冲突，所以我决定将我的所有更改压缩到1次提交并在上游重新绑定它，但是我放弃了我的提交历史。 有没有办法让这个过程不那么痛苦？

Answer 1

我不知道但是：

  

通常我每隔 2个月更新一次上游，但这个过程非常痛苦 - 需要一周时间，工作停止，合并后出现许多错误。

我认为，如果你在积极发展的大师身上落后2个月，那你就是在乞求麻烦。

1. 我建议你制作更小的功能。更频繁地执行较小的合并。但如果您无法拆分功能，这可能不太可行。
2. 或者，将master合并到您的功能分支中以测试，然后更新上游 无论如何你必须测试它。这样就会出现bug，而不是维护者。

Answer 2

如果您必须在快速变化的项目中维护自己的补丁，则没有魔术按钮。 git rebase是一个正确的工具，因为它可以很好地记账，但它本身无法解决冲突。有一些事情可以帮助你。它们与您使用的技术大多无关。

• （正如其他答案所示）尝试更频繁地更新，并添加单元测试
• 使您的更改变小，不要尝试修复上游编码风格等。在IDE中禁用自动重新格式化。有时违反关于缩进的风格是有道理的。
• 仔细构建您的更改。将它分为如下提交：
  • 上游代码的非功能性重构，它将为您的功能包含准备项目。它们几乎总会发生冲突，但如果你有高级别的描述，你可以从头开始相对轻松地重做它们（例如＆＃34;将X功能提取到带有Y名称的功能＆＃34;）
  • 在您添加的新文件中实现的独有逻辑片段。然后他们永远不会发生冲突。
  • 通过在此处添加或更改几行来将您的功能包含到项目中。他们有时会发生冲突，但应该很容易重做。
• 向上游，全部或部分贡献您的更改