在Git仓库中重写一条提交消息,并使用非线性历史记录

6pp0gazn  于 12个月前  发布在  Git
关注(0)|答案(2)|浏览(104)

我需要更改过去提交的消息。
我尝试了如何通过SHA1哈希改写Git提交中描述的方法?也就是说,检查出有问题的提交,修改其消息并手动变基回当前分支。这失败了:

$ git checkout dad667e92fcea4c
Note: switching to 'dad667e92fcea4c'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
(...)
HEAD is now at dad667e Merge branch 'master' of <MESSAGE>

$ git commit --amend
[detached HEAD 650dc88] Merge branch 'master' of master on GitLab
 Author: laroc <[email protected]>
 Date: Tue Mar 5 11:36:02 2019 +0100

$ git rebase HEAD master
Auto-merging src/main/java/ch/SomeClass.java
CONFLICT (content): Merge conflict in src/main/java/SomeClass.java
Auto-merging src/main/java/OtherClass.java
error: could not apply 369e489... OPENSRC-75
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 369e489... OPENSRC-75
(...)

所以我尝试了另一种方法,在How do I rebase while skipping a particular commit中描述的?:git interactive rebase.这与第一种方法完全相同:

$ git rebase -i HEAD~172
Auto-merging src/main/java/SomeClass.java
CONFLICT (content): Merge conflict in src/main/java/SomeClass.java
Auto-merging src/main/java/OtherClass.java
CONFLICT (content): Merge conflict in src/main/java/OtherClass.java
error: could not apply 369e489... OPENSRC-75
(...)

问题似乎源于项目的Git历史不是线性的:它包含分支,以及合并提交,以解决并发开发人员的冲突。看起来上面的命令试图再次解决所有过去的冲突。但是我不想改变提交源代码中的任何东西-我只想改写一个提交!

ruarlubt

ruarlubt1#

而不是git rebase,我建议您
1.使用git replace --edit dad667e92fcea4c编辑提交消息,
1.然后使用git filter-repo将新的替换提交烘焙到历史中。
您可以找到如何执行第二步in this answer的说明。

sigwle7e

sigwle7e2#

但是我不想改变提交源代码中的任何东西-我只想改写一个提交!
这不重要所有Git提交都是不可变的。Git的工作是保存历史,并准确地保存它。我的意思是 * 确切 *。这包括它的提交消息,它的日期,它的出身-一切。
没有所谓的更改提交。Git不允许这样做。一个提交只能被重建--用一个新的、不同的提交替换。
这也包括亲子关系。一个被重建(替换)的父提交必须被重建(替换)。
因此,你不能改变过去提交的任何东西--无论你认为这个改变有多小--而不同时改变(重建)所有的后续提交。您的提交将被替换,因此所有后续提交也必须被替换。
因此,所有后续的合并都必须再次执行,包括冲突解决(如果存在冲突)。

相关问题