让我们说一些开发人员在他的分支中工作并做这些提交:
A -> B -> C -> D -> E
我是审稿人,我注意到在提交B中,某些文件已被更改,但不应该是。
我试图找到解决此案的最佳方法,我想这样做:
A -> B -> X -> Y -> C -> D -> E
其中:
我正在考虑做以下事情,但我知道它看起来并不完全相同:
以上是否有效?这是最好的方式还是有更好的方法?
注意:我有兴趣听到任何涉及重写历史的解决方案。
答案 0 :(得分:4)
由于此分支已向上游推送并公开 - 不重写其历史记录。这将打破其他开发者的分支。
你应该做的是:
A -> B -> C -> D -> E -> X -> Y
将历史记录保持到E(我假设为HEAD
)。然后git revert B
将错误提交恢复为提交X
。然后使用您的提交Y
修复它。
或者,您可以git revert -n B
,它将等待提交并允许您编辑提交,从而在一次提交中只包含所有修复(仅X
,不Y
)。这是解决此问题的更优雅方式。
答案 1 :(得分:3)
恢复B本身是一个单独的提交,因为你自己已经指出(X)和(Y)再次是一个没有不需要的文件的额外提交。为什么不删除不需要的文件并提交一次而不还原原始提交?像这样: A - > B - > C - > D - > E - > ž 如果提交Z仍然存在,则提交Z将删除不需要的文件。
答案 2 :(得分:1)
所以我找到了一个符合我需要的解决方案rebase -i
(我不关心在这个功能分支案例中重写历史记录)
我喜欢它,因为它可以满足我的需要:手动删除文件,我想从提交中删除,而不是合并。
答案 3 :(得分:0)
Yuval的答案是开发此分支的正确方法,但如果这是一个与主分支分开处理的功能分支,将来会合并(例如,这些提交在dev
上主分支是master
):
X
还原并根据Yuval的回答修复Y
git rebase -i master
X
和Y
以紧跟B
X
和Y
标记为fixup
,然后将其压缩为B
C
,D
和E
您现在拥有一个本地dev
分支,其中包含您所需顺序的提交。您现在可以将此分支合并到master
并删除dev
分支;通过这种方式,您可以获得所需的干净历史,而不会破坏任何人的开发工作。