git rebase在提交中留下额外的“分支”

时间:2017-11-14 16:03:12

标签: git git-rebase

我试图将一些旧的提交压缩在一起,已经被推到了掌握之中。我是唯一的开发人员,所以强制更新存储库是好的。我从这开始:

% git log --oneline --decorate --graph --all
* 4b2fec5 (HEAD -> master, tag: v6.2.5, origin/master, origin/HEAD) Version 6.2.5 - Fixed MegaMillions payout bug
* b0ae8a9 (tag: v6.2.4) Version 6.2.4 - Handles large size text
* f4763bd (tag: v6.2.3) 6.2.3
* 3f02a27 (tag: v6.2.1) Version 6.2.1
* 7703d55 (tag: v6.2.0) Updated revision
* a2c6366 Removed legacy NSNotification stuff.
* 1e3b359 Changes UITextFieldTextDidChange to use an onPost  handler.
* 35b910b Turns off the request for app store rating.
* 5c20d46 Put the detail segue back in.
* f90722d Got rid of stack view from MasterViewController
* eb34f07 Removed unnecessary null coalesce operator.
* c969126 Changed for Megamillions new payout structure.
* 2a32838 Version 6.2.0
* efb33b0 Initial commit
* 13a5b0e (tag: v6.0.1) 6.0.1 for app store
* 45ab2ba Downloads new numbers after creating a new ticket now.
* 2d60f30 Cancel button didn't have an exit segue on the master.
* 2185112 Changed to static size text for loser
* 872f408 Initial Commit

现在我想把v6.2.0标签和版本6.2.0提交之间的所有内容压缩成一个提交,所以我做了一个 git rebase -i efb33b0表示成功。但是现在我留下了以下内容:

% git log --oneline --decorate --graph --all
* 0fb2623 (HEAD -> master) Version 6.2.5 - Fixed MegaMillions payout bug
* 81d3553 Version 6.2.4 - Handles large size text
* d7d7578 6.2.3
* eae8973 Version 6.2.1
* ded0fe9 Version 6.2.0
| * 4b2fec5 (tag: v6.2.5, origin/master, origin/HEAD) Version 6.2.5 - Fixed MegaMillions payout bug
| * b0ae8a9 (tag: v6.2.4) Version 6.2.4 - Handles large size text
| * f4763bd (tag: v6.2.3) 6.2.3
| * 3f02a27 (tag: v6.2.1) Version 6.2.1
| * 7703d55 (tag: v6.2.0) Updated revision
| * a2c6366 Removed legacy NSNotification stuff.
| * 1e3b359 Changes UITextFieldTextDidChange to use an onPost  handler.
| * 35b910b Turns off the request for app store rating.
| * 5c20d46 Put the detail segue back in.
| * f90722d Got rid of stack view from MasterViewController
| * eb34f07 Removed unnecessary null coalesce operator.
| * c969126 Changed for Megamillions new payout structure.
| * 2a32838 Version 6.2.0
|/
* efb33b0 Initial commit
* 13a5b0e (tag: v6.0.1) 6.0.1 for app store
* 45ab2ba Downloads new numbers after creating a new ticket now.
* 2d60f30 Cancel button didn't have an exit segue on the master.
* 2185112 Changed to static size text for loser
* 872f408 Initial Commit

如何摆脱那里的额外“分支”?基本上它看起来像右边的整个分支只需要消失,所以它只跟随主路径......并以某种方式改变标签。

1 个答案:

答案 0 :(得分:1)

简短的回答是你不能/不能。 (但请参见下面的例外情况。)

git rebase所做的是复制一些提交以进行新的,不同的提交,然后放弃原始的提交集合以支持新的 - - 改进了提交。

此时遇到的问题是,当且仅当您正在“开启”分支时,放弃这些提交才能正常(如git status中所述on branch master )是那些特定提交的唯一引用。如果对某些或所有原始提交有其他参考,那些引用不会改变!

如果这些引用位于某些其他存储库中,甚至可能尤其如此。如果您有git push - 提交到其他某个存储库并让其他存储库设置其某些引用以记住这些提交,则可能会发生后者。这就是为什么修改或重新提交已经git push编辑的提交通常不是很好的原因。

(小方注意:引用是Git对分支和标记名称的概括。有更多种类,但这两种是最熟悉的。分支名称只是完整名称以refs/heads/开头:名称的其余部分是分支名称。因此refs/heads/master是分支名称master的完整引用名称。)

可以完成,如果每个人都可以

如果

  • 确定没有其他人将这些提交哈希存储在其他一些克隆中,或者
  • 您已经预先安排了所做的其他人将这些提交哈希存储起来,每个人都会根据需要切换所有他们的参考文件,

然后(并且只有那时)这样可以重新定义共享提交。为此,在将旧的,略有缺陷的提交复制到闪亮的新提交之后,您必须找到使用旧提交的所有引用(在所有存储库副本中!),并移动它们以便它们引用而不是闪亮的新提交。

在你的情况下,我至少计算六(6)个这样的参考:

  1. tag v6.2.0(refs/tags/v6.2.0);
  2. tag v6.2.1;
  3. tag v6.2.3;
  4. tag v6.2.4;
  5. tag v6.2.5;
  6. 分支masterorigin处的另一个Git上,你的Git正在记住你的origin/master(那是他们的refs/heads/master和你的refs/remotes/origin/master
  7. 如果你说服他们移动他们的master(例如通过强制推送),你refs/remotes/origin/master引用中你自己的Git内存将自动改变。如果你说服他们移动所有其他五个标签,你移动所有五个标签,这将消除所有六个这些名称 - 旧的提交。 Git将停止向您显示旧提交,最终它们将真正过期并被垃圾收集起来。

    强制推送新的master,你可以git push --force origin master(但暂时搁置一下)。这仍然会让您逐个重新调整每个标记,以指向闪亮的新复制提交 - 每个提交具有不同的新的闪亮哈希ID - 然后强制推送那些标记git push --force --tags,并希望他们(“他们”在origin上的任何人)允许所有这些强制推动。您可以使用git push --force --tags master一次性全部推送它们。

    更改其他人的参考资料的问题在于获取所有。否则旧的引用,以及旧的提交,可能会回来困扰你。但是,如果您的Git和origin上的Git是此存储库的唯一副本,并且您可以控制这两个副本,那么可以执行您想要的操作。