我有以下提交历史记录:
头部头部~头部~2头部~3
gitcommit--修改当前HEAD提交。但是如何修改HEAD~3?
我有以下提交历史记录:
头部头部~头部~2头部~3
gitcommit--修改当前HEAD提交。但是如何修改HEAD~3?
当前回答
git存储+再基础自动化
因为当我需要多次修改Gerrit审查的旧提交时,我一直在做:
git-amend-old() (
# Stash, apply to past commit, and rebase the current branch on to of the result.
current_branch="$(git rev-parse --abbrev-ref HEAD)"
apply_to="$1"
git stash
git checkout "$apply_to"
git stash apply
git add -u
git commit --amend --no-edit
new_sha="$(git log --format="%H" -n 1)"
git checkout "$current_branch"
git rebase --onto "$new_sha" "$apply_to"
)
GitHub上游。
用法:
修改源文件,如果已在repo中,则无需gitaddgit修改旧$old_sha
我很喜欢这一点,因为它不会挤压其他无关的修复。
其他回答
使用git-rebase。例如,要修改提交bbc643cd,请运行:
$ git rebase --interactive 'bbc643cd^'
请注意命令末尾的插入符号^,因为您实际上需要在要修改的提交之前重新返回提交。
在默认编辑器中,在提到bbc643cd的行中修改pick以进行编辑。
保存文件并退出。git将解释并自动执行文件中的命令。您将发现自己处于之前创建提交bbc643cd的情况。
此时,bbc643cd是您最后一次提交,您可以很容易地修改它。进行更改,然后使用以下命令进行提交:
$ git commit --all --amend --no-edit
之后,使用以下命令返回到上一个HEAD提交:
$ git rebase --continue
警告:请注意,这将更改该提交的SHA-1以及所有子项——换句话说,这将重写从此点开始的历史。如果使用命令gitpush-force进行推送,则可以断开repos。
对我来说,这是为了从回购中删除一些凭证。我试着换基,在换基的过程中遇到了一大堆看似无关的冲突——继续。不要费心尝试重新设置自己的基础,在mac上使用名为BFG(brew-install-BFG)的工具。
完全非交互式命令(1)
我只是想分享一个我正在使用的别名。它基于非交互式交互式数据库。要将其添加到git中,请运行以下命令(解释如下):
git config --global alias.amend-to '!f() { SHA=`git rev-parse "$1"`; git commit --fixup "$SHA" && GIT_SEQUENCE_EDITOR=true git rebase --interactive --autosquash "$SHA^"; }; f'
或者,一个也可以处理未暂存文件的版本(通过先暂存,然后再卸载):
git config --global alias.amend-to '!f() { SHA=`git rev-parse "$1"`; git stash -k && git commit --fixup "$SHA" && GIT_SEQUENCE_EDITOR=true git rebase --interactive --autosquash "$SHA^" && git stash pop; }; f'
这个命令的最大优点是它不是vim。
(1) 当然,考虑到重新启动期间没有冲突
用法
git amend-to <REV> # e.g.
git amend-to HEAD~1
git amend-to aaaa1111
将名称修改为似乎合适IMHO。将流程与--修订:
git add . && git commit --amend --no-edit
# vs
git add . && git amend-to <REV>
解释
git-config—全局别名<名称>'<COMMAND>'-创建名为<NAME>的全局git别名,该别名将执行非git命令<COMMAND>f(){<BODY>};f-一个“匿名”bash函数。SHA=`git rev parse“$1”`;-将参数转换为gitrevision,并将结果赋给变量SHAgitcommit--fixup“$SHA”--fixup提交SHA。参见git提交文档GIT_SEQUENCE_EDITOR=true GIT rebase--交互式--autosquash“$SHA^”gitrebase——交互式“$SHA^”部分已被其他答案覆盖。--autosquash与gitcommit一起使用--fixup,有关更多信息,请参阅gitrebase文档GIT_SEQUENCE_EDITOR=true是使整个事情非交互式的原因。这是我从这篇博客文章中学到的。
基于文档
修改旧的或多个提交消息的消息
git rebase -i HEAD~3
上面显示了当前分支上最后3次提交的列表,如果需要更多,请将3更改为其他内容。列表将类似于以下内容:
pick e499d89 Delete CNAME
pick 0c39034 Better README
pick f7fde4a Change the commit message but push the same commit.
将pick替换为要更改的每个提交消息之前的改写。假设您更改了列表中的第二个提交,您的文件将如下所示:
pick e499d89 Delete CNAME
reword 0c39034 Better README
pick f7fde4a Change the commit message but push the same commit.
保存并关闭提交列表文件,这将弹出一个新的编辑器,供您更改提交消息、更改提交消息并保存。
最后,强制推行修改后的承诺。
git push --force
嗯,这个解决方案可能听起来很愚蠢,但在某些情况下可以拯救你。
我的一个朋友刚刚无意中提交了一些非常大的文件(四个自动生成的文件,每个文件的大小在3GB到5GB之间),然后在此基础上提交了一些额外的代码,然后才意识到git推送不再有效的问题!
这些文件已在.gitignore中列出,但在重命名容器文件夹后,它们被暴露并提交了!现在,在上面还有几次代码提交,但推送一直在运行(试图上传GB的数据!),最终由于Github的文件大小限制而失败。
交互式rebase或任何类似的问题是,他们会处理这些巨大的文件,并且会花费很长时间来做任何事情。然而,在CLI中花了将近一个小时后,我们不确定文件(和增量)是否真的从历史中删除了,或者只是不包括在当前提交中。推也不起作用,我的朋友真的卡住了。
因此,我提出的解决方案是:
将当前git文件夹重命名为~/Project old。再次从github克隆git文件夹(到~/Project)。签出到同一分支。手动将文件从~/Project旧文件夹cp-r到~/Project。确保不需要签入的大量文件被mved并正确包含在.gitignore中。还要确保您没有用旧文件夹覆盖最近克隆的~/Project中的.git文件夹。这就是有问题的历史记录的所在!现在查看更改。它应该是所有最近提交的联合,不包括有问题的文件。最后提交更改,这很好。
这个解决方案最大的问题是,它处理手动复制一些文件,并且它将所有最近的提交合并为一个(显然使用了一个新的提交哈希)
最大的好处是,它在每一步中都非常清晰,它适用于大型文件(以及敏感文件),并且不会在历史上留下任何痕迹!