这是可以做到,但要注意,如果你已经发布的提交(因为它听起来像你有),那么不建议任何编辑历史。所以有一些可能的程序。为了这些解释的目的,我将假定这些变化在分支my_branch
上。 (它工作正常,如果有问题的分支是master
;我只需要承担东西与写命令)
简单,但笨重的
你可以回到以前的承诺,创建临时分支,并在该分支上创建您的中间提交。然后告诉审阅者首先检查临时分支上的更改,然后将您的my_branch
与临时分支区别开。如果你的评论者会为此付出代价,那么它就会给他们更简单的差异而不会混乱。但也许它不会以最好的方式保存历史。
随着历史重写
如果你能做到这一点,这将让您有一个更清洁的历史。但它涉及历史重写,并且如上所述,这可能会导致其他用户推出更改的任何回购问题。见git rebase
文档重:从上游恢复变基
如果这不是一个问题,或者如果您发现该恢复过程是可以接受的,那么你可以这样做:
首先,收银台前提交到变化。我假设这是
git checkout my_branch^
现在你处于分离头状态。也许好创建一个临时分支:
git checkout -b temp_branch
复制main
到aux
和承诺。
接下来,您需要一个与my_branch
HEAD类似的提交,但您希望其父代为temp_branch
HEAD。如果aux
是在改变的唯一承诺:
git checkout my_branch -- aux
git commit
git branch -f my_branch
如果在提交的其他变化,那么它可能会更容易重新家长它。还有如何在这一点上,你可以清理temp_branch
做到这一点的文档中的git filter-branch
(https://git-scm.com/docs/git-filter-branch)
当然股票的例子。您可能需要“强制推送”my_branch
(如果它已经发布)。
git checkout my_branch
git push -f
而这所有其他的开发人员可能需要恢复,如果他们也有提及my_branch
信号。
没有历史重写
如果没有以上可以正常工作,那么你可以尝试这样的:首先,使用git revert
回去变化之前。然后,分两个阶段重新应用提交。
再次,中间提交很容易做出(与重写的情况相同)。如果对main
和aux
的更改是提交中的唯一更改,那么您可以再次从原始提交中提取aux
以简化创建最终提交。但是,这一次的命令将
git checkout HEAD^ -- aux
因为HEAD
是复归犯这样HEAD^
是一个与它的变化。
如果提交有其他修改,然后一个braoder
git checkout HEAD^ -- .
可能会做,但我会先倾向于rm -r
工作树刚走出偏执。你尝试的任何步骤,您就可以验证你与
git diff HEAD^
正确地重建了最终的树那么现在你有这个奇怪的背部和反复诠释他的历史,但没有改写,并没有“第二支”参与了简化验证。当然,您可能还需要分两步进行验证:首先显示HEAD^
等于先前验证的状态,然后验证从HEAD^
到HEAD
的补丁。
您是否将此举作为单独提交进行提交,或者您是否移动了内容,然后进行编辑,然后进行提交? (关于你已经做了什么) –
不,不幸的是,我有移动和编辑作为一个单一的提交。 –