1

好的，有 2 个项目，A 和 B。我正在处理的项目“B”在“A”的下游。也就是说，B 与 A 相比，添加了不同的功能，并朝着不同的方向成长。但它们有着共同的历史。

不久前，B 会随着 A 的每个主要版本定期更新而得到维护。但现在情况已不再如此。

在追踪 B 中的内存泄漏时，我发现它在一年前已在 A 中修复，然后对 A 进行了大量更改以提高性能。

决定将所有这些更改集成到项目 B 中。

所以这就是我现在正在做的。显然，有不少困难使这项任务难以管理。但它们都与我的问题无关。

我开始逐个创建 diff 的组件，以查看发生了什么变化并决定可以包含哪些内容，而不会破坏 A 中不存在的 B 中的功能。

我为每个组件创建了一个新分支（为了使其更易于管理 - 识别在特定组件之外更改代码的引用是什么）最初认为我可以进行合并，我似乎记得在之前使用合并它会产生冲突而不是过度写作；但是无论出于何种原因，当我尝试将 A 中的组件与 B 合并时，大部分 B 独有的代码都丢失了。

不过，什么可以起作用，我不愿意花时间在我不知道的可能出现坑的技术上，只是编辑从差异创建的补丁。

然后应用编辑的补丁。

因为在补丁中我可以并排看到代码的两面，我可以删除不希望删除代码的位 (-)，并逐个考虑冲突。

有没有人试过这个？或者有人知道处理这类问题的更主流技术吗？

另一个问题是如何在不被 git 系统破坏的情况下更改补丁？

4

1 回答 1

1

我建议不要编辑 git 补丁，而是挑选有趣的提交，并在工作目录中修改应用的差异：

git cherry-pick --no-commit upstream/commit1
(edit changes in working directory)
git commit

如果你有很多潜在有趣的提交，你可以尝试交互式 rebase。

git checkout upstream/master -b upstream-new
git rebase -i master

通过这种方式，您可以轻松地查看和挑选大量提交 - 例如，仅选择仅影响子系统的提交。您可以通过运行来帮助选择过程git log --oneline subsystem1/ >/tmp/subsystem1_commits.txt- 它将创建一个语法与git rebase -i.

关于您的工作流程：我认为您的问题没有简单的解决方案。如果上游仓库和你的分支长期分歧，你将失去 git 的主要优势：易于分支和合并。您将剩下的几乎是手动修补系统，这总是很痛苦。但是，如果您可以每年更新一次或两次上游存储库，则可能值得执行以下操作：

  • 从上游/master 版本开始，将您的提交应用到它（=> 您的 master-1 分支）
  • 需要时从上游/主服务器中挑选修补程序
  • 当你有时间更新到上游分支时，将你的 master-1 分支重新定位到上游/master，但没有已经挑选好的修补程序（你可以用 来做到这一点git rebase -i）。我们称这个分支为 master-2。

这样，您将拥有以下历史记录：

A-A-A-A-A- (upstream/master at the beginning)
          \
           -B-B-A-B (your master-1 branch, with a cherry-pick)
          \
           -A-A-A-A-A-A-A-A -B-B-B (your master-2 branch, after the rebase)
于 2012-05-07T00:18:51.247 回答