1

假设在他的分支中进行一些开发工作并进行这些提交：

A -> B -> C -> D -> E

我是审阅者，我注意到在提交 B 中，一些不应该更改的文件已更改。

我正在尝试找到解决这种情况的最佳方法，我想做：

A -> B -> X -> Y -> C -> D -> E

在哪里：

  • X 是 B 的回归
  • Y 是 B，没有不必要的更改

我正在考虑执行以下操作，但我知道它看起来并不完全相同：

  • B 上的 git checkout -b
  • 在 X 中恢复 B
  • 在 Y 中以更好的方式做 B
  • 在我的分支中合并 CDE
  • 将所有内容放回 dev 分支

上述方法有效吗？这是最好的方法还是有更好的方法？

注意：我很想听听任何涉及重写历史的解决方案。

4

4 回答 4

4

由于这个分支已被推向上游并公开 -不要重写它的历史。这将破坏其他开发人员的分支。

你应该做的是：

A -> B -> C -> D -> E -> X -> Y

保持历史直到 E （我假设是HEAD）。然后git revert B它将错误的提交恢复为 commit X。然后用你的 commit 修复它Y。

或者，您可以git revert -n B，它将等待提交并允许您编辑提交，从而在单个提交中包含所有修复（X仅，否Y）。这是处理这个问题的更优雅的方式。

于 2012-12-04T12:57:11.043 回答
3

正如您自己指出的那样，恢复 B 本身是一个单独的提交， (X) 和 (Y) 再次是一个额外的提交，没有不需要的文件。为什么不删除不需要的文件并提交一次而不恢复原始提交？像这样： A -> B -> C -> D -> E -> Z 提交 Z 删除不需要的文件（如果它们仍然存在）。

于 2012-12-04T12:59:57.810 回答
1

所以我找到了一个适合我需要的解决方案rebase -i（我不在乎在这个功能分支案例中重写历史）

  • git rebase -i A （B 之前的提交）
  • git reset HEAD^1 文件名（在不需要更改的文件上尽可能多地执行此操作）
  • git commit --amend
  • git rebase -- 继续

我喜欢它，因为它确实满足了我的需要：手动删除我想从提交中删除的文件，而不是合并。

于 2012-12-04T13:28:17.513 回答
0

Yuval 的回答是开发这个分支的正确方法，但是如果这是一个与主分支分开工作的特性分支，并且将来会被合并（例如，这些提交是打开dev的，主分支是master）：

  1. 根据 Yuval 的回答恢复X并修复Y
  2. 正常发展
  3. 当要合并功能时，运行git rebase -i master
  4. 移动X并Y立即跟随B
  5. 可选地，标记X和Y作为fixup，它们将被压缩成B
  6. 修复C,D和E

您现在有一个本地dev分支，其中按您想要的顺序提交。您现在可以将此分支合并到master并删除该dev分支；这样，您就拥有了您想要的干净历史，而不会破坏任何人的开发工作。

于 2012-12-04T13:29:18.277 回答