我有以下提交历史记录:

头部头部~头部~2头部~3

gitcommit--修改当前HEAD提交。但是如何修改HEAD~3?


当前回答

当我需要更深入地修复历史中以前的提交时,我经常使用交互式rebase和--autosquash。它本质上加快了ZelluX的回答所说明的过程,当您需要编辑多个提交时,它特别方便。

根据文档:

--自动撤销当提交日志消息以“squash…​“(或”修复…​“),并且有一个提交的标题以相同的开头…​, 自动修改rebase-i的todo列表,以便标记为挤压的提交在要修改的提交之后立即出现

假设您的历史记录如下:

$ git log --graph --oneline
* b42d293 Commit3
* e8adec4 Commit2
* faaf19f Commit1

并且您有要修改为Commit2的更改,然后使用

$ git commit -m "fixup! Commit2"

或者,您可以使用commit sha而不是commit消息,因此“fixup!e8adec4”或甚至只是commit消息的前缀。

然后在提交之前启动交互式重新基础

$ git rebase e8adec4^ -i --autosquash

编辑器将打开已正确排序的提交

pick e8adec4 Commit2
fixup 54e1a99 fixup! Commit2
pick b42d293 Commit3

你只需要保存并退出

其他回答

如果出于某种原因,您不喜欢交互式编辑器,可以使用gitrebase--on。

假设您要修改Commit1。首先,从Commit1之前分支:

git checkout -b amending [commit before Commit1]

第二,用樱桃核抓取Commit1:

git cherry-pick Commit1

现在,修改您的更改,创建Commit1':

git add ...
git commit --amend -m "new message for Commit1"

最后,在隐藏了任何其他更改后,将其余的提交移植到master之上新提交:

git rebase --onto amending Commit1 master

阅读:“将Commit1(不包括在内)和master(包括在内)之间的所有提交重新纳入修改分支”。即Commit2和Commit3,将旧的Commit1完全删除。你可以随便摘,但这样更容易。

记得清理你的树枝!

git branch -d amending

嗯,这个解决方案可能听起来很愚蠢,但在某些情况下可以拯救你。

我的一个朋友刚刚无意中提交了一些非常大的文件(四个自动生成的文件,每个文件的大小在3GB到5GB之间),然后在此基础上提交了一些额外的代码,然后才意识到git推送不再有效的问题!

这些文件已在.gitignore中列出,但在重命名容器文件夹后,它们被暴露并提交了!现在,在上面还有几次代码提交,但推送一直在运行(试图上传GB的数据!),最终由于Github的文件大小限制而失败。

交互式rebase或任何类似的问题是,他们会处理这些巨大的文件,并且会花费很长时间来做任何事情。然而,在CLI中花了将近一个小时后,我们不确定文件(和增量)是否真的从历史中删除了,或者只是不包括在当前提交中。推也不起作用,我的朋友真的卡住了。

因此,我提出的解决方案是:

将当前git文件夹重命名为~/Project old。再次从github克隆git文件夹(到~/Project)。签出到同一分支。手动将文件从~/Project旧文件夹cp-r到~/Project。确保不需要签入的大量文件被mved并正确包含在.gitignore中。还要确保您没有用旧文件夹覆盖最近克隆的~/Project中的.git文件夹。这就是有问题的历史记录的所在!现在查看更改。它应该是所有最近提交的联合,不包括有问题的文件。最后提交更改,这很好。

这个解决方案最大的问题是,它处理手动复制一些文件,并且它将所有最近的提交合并为一个(显然使用了一个新的提交哈希)

最大的好处是,它在每一步中都非常清晰,它适用于大型文件(以及敏感文件),并且不会在历史上留下任何痕迹!

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

我很喜欢这一点,因为它不会挤压其他无关的修复。

采用这种方法(它可能与使用交互式rebase完全相同),但对我来说,这有点简单。

注:我提出这种方法是为了说明你能做什么,而不是日常的选择。因为它有很多步骤(可能还有一些警告)

假设您要更改提交0,并且您当前处于功能分支

some-commit---0---1---2---(feature-branch)HEAD

签出此提交并创建一个快速分支。您还可以将功能分支克隆为恢复点(启动之前)。

?(git checkout -b feature-branch-backup)
git checkout 0
git checkout -b quick-branch

现在,您将看到如下内容:

0(quick-branch)HEAD---1---2---(feature-branch)

换舞台,把其他东西都藏起来。

git add ./example.txt
git stash

提交更改并签回功能分支

git commit --amend
git checkout feature-branch

现在,您将看到如下内容:

some-commit---0---1---2---(feature-branch)HEAD
           \
             ---0'(quick-branch)

将功能分支重新设置为快速分支(解决过程中的任何冲突)。涂抹涂抹物并移除快速分支。

git rebase quick-branch
git stash pop
git branch -D quick-branch

最后你会得到:

some-commit---0'---1'---2'---HEAD(feature-branch)

Git不会在重基时复制0提交(虽然我不能说在多大程度上)。

注意:所有提交散列都是从我们最初打算更改的提交开始更改的。

我执行以下操作,包括更改本地提交的日期和时间:

git rebase -i HEAD~6

~6是要显示的提交历史记录的数量。

从pick更改为编辑要编辑的提交。然后我保存并退出(在ubuntu中:Ctrl+O保存,Ctrl+X退出)然后我运行:gitcommit--modify--date=“2022-09-02TT1:10:04”-m“NEW_MSG”如果编辑已打开,只需保存并退出即可。然后,为了确认并转到下一个提交或完成(如果是最后一个),我执行:gitrebase--continue

如果有更多提交要编辑,则从第1点开始重复

最后,我验证更改,如果一切正常,我会推送