这是这样一种情况。带注释的示例提交历史记录。
- 正常commit,推送到github
- 正常提交
- 一次提交意外获得了一个新的 200 MB 文件
- 另一个承诺。
- 提交其中发现问题,文件已通过 git rm 删除
但是现在如果你将所有这些推送到github,那么你会遇到一个麻烦:那里不接受大文件,虽然它似乎不在提交5及更远的地方,但它在提交3和4中,虽然原则上不需要,但推送仍然尝试上传它。
在这种情况下,正确的做法是什么?当然,作为一个选项 - 回滚到提交 2,并手动重新添加所有内容,这在提交 3 和 4 中。但这似乎不是一个好的解决方案。最好的方法是什么?
通过删除与有问题的文件相关的提交来重写历史记录
然后将分支设置为新的下一个提交并推送。
如果<新文件意外进入的提交>需要在没有该文件的情况下保存,则先切换到该提交,删除该文件并进行更改,然后使用该编辑的提交进行迁移
git commit --amend。一个更简单的(嗯,怎么看)选项:
此命令将生成一个包含提交列表的文件,并在默认文本编辑器中打开它(请注意,如果您没有设置它,这可能是 vi)。
接下来,您需要找到第 5 次提交的行,将 pick 命令更改为 fixup,并在第三次提交之后立即重新排列。之后,您需要保存文件并退出编辑器。
如果您尚未完成第五次提交,则可以使用更简单的选项。在这种情况下,可以使用 key 来完成
--fixup,然后在 autosquash 模式下应用 rebase:在这种情况下,git rebase 将根据需要立即打开一个已排序的提交列表,您只需确保一切正确并退出文本编辑器即可。
PS 不要忽视 GUI 的存在。普通工具可以让你完成我上面写的所有事情,而无需记住命令和挖掘法力。Windows下的正常GUI,如果有的话是Git扩展,在Linux下,似乎也有一些东西。