git rebase交互式已经推送的提交 [英] git rebase interactive already pushed commits
问题描述
最近，我在更改提交消息时重新建立了仅本地存储库的成功，此后仅更改了提交消息，但历史记录本身未更改.
Recently I had a lot of success rebasing a local-only repository while changing commit messages and after that only the commit messages had been changed but the history itself hasn't.
现在我有了我的存储库-远程和本地.我在多个分支上进行了几次提交，并且已经推送了它们.由于某些原因，我需要在几个分支上更改一些提交量，并像以前一样尝试使用rebase交互式.但是提交出现在当前检出分支的末尾.
Now I have my repositories - remotely and locally. I made several commits on several branches and already pushed them. Due some reasons I need to change some commit masseages over several branches and tried to use rebase interactive like before. But the commits appeared at the end of the current checked out branch.
(我知道该如何做，在重新建立基础之前我已将存储库重置为该状态.)
(I know how to and I had reset my repositories to the state before rebasing.)
经过一番阅读后，我意识到问题是提交已经被推送了，这不是我的仅限本地存储库中的事实.
After some reading I realized the problem is the commits had been pushed already which wasn't the fact in my local-only repository.
我试图重新建立远程存储库的基础，但这只是一个裸露的库-因此无法正常工作.
I tried to rebase the remote repository, but it's a bare one - so it didn't work.
我知道不推荐这样做.但是出于学习目的，我真的很想知道如何更改多个提交消息，而又不会在分支机构/存储库的末尾产生重复的提交.
I know its not recommended. But for learning purposes I really like to know how to change several commit messages without resulting in duplicate commits at the end of my branch / repository.
(我不喜欢这种解决方案，不能将其本地存储库复制并更改为一个裸露的存储库作为新的远程存储库，这可以解决我的问题.)
(I don't like the solution to work on, to copy and to change my local repository to a bare one as my new remote repository, which would solve my problem.)
我希望我能说得足够清楚.谢谢.
I hope I made myself clear enough. Thanks.
推荐答案
更改提交消息会导致更改提交的哈希值，这意味着随后的所有提交也必须更改其哈希值(因为父级包含在哈希计算中) ，因为消息本身也是).
Changing the commit message results in changing the commit's hash value and this means all following commits have to change their hashes too (as the parent is included in the hash computation, as the message itself is too).
这就是为什么通常仅在本地分支机构中允许重新定级的原因.许多人说，大多数git远程存储库都允许重写推送的历史记录，因为任何人都可以下载它，然后可以处理过时的历史记录/分支/提交.
This is why rebasing is typically only allowed in local branches. Many or say most git remote repositories permit rewriting the pushed history as anyone could have downloaded it already and would then work on a outdated history/branch/commit.
但是，如果您的服务器确实允许历史记录重写(例如，如果您是唯一正在处理它的服务器)，则可以使用--force推送它们.
However if your server does allow history rewrites (e.g. if you are the only one working on it) you may push them with --force.
作为旁注，请参见此处 https://stackoverflow.com/a/5668050/1756183
As a side note see here https://stackoverflow.com/a/5668050/1756183
编辑具有多个分支的变基:
Edit rebase with several branches:
C1 <- C2 <- C3 (branch1)
将C1的子级重新定位会导致
rebasing children of C1 results in
C1 <- CR2 <- CR2 (branch1)
但是，如果您有:
/ C4 <- C5 (branch2)
C1 <- C2 <- C3 (branch1)
重定基极有可能导致:
/ C2 <- C4 <- C5 (branch2)
C1 <- CR2 <- CR3 (branch1)
原因是C2仍是C4的父级，固定"提交CR2仅与重写的分支branch1有关.
如果要忘记" C2，则必须在CR2的基础上重新设置C4(您必须使用rebase --onto进行操作).之后，C2不会被视为任何人的父级或任何分支，也不会显示在历史记录中(尽管直到垃圾收集它仍然存在).
the reason is that C2 is still the parent of C4, the "fixed" commit CR2 is only related to the rewritten Branch branch1.
If you want to "forget" C2 you have to rebase C4 on top of CR2 (you ll have to play around with rebase --onto). After that C2 is not adressed as anyone's parent or on any branch and will not be shown in the history (although it is still there until garbage collected).
这篇关于git rebase交互式已经推送的提交的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
