git squash几个合并提交

时间:2016-04-18 15:28:31

标签: git

我检查了一个本地分支,对它做了几次提交,然后把我的分支推到了原点。我的老板想把我的分支合并到主人,但显然他的印象是他必须单独合并每个提交,而不是仅仅将我推出的分支合并到主人。结果,我们的git历史现在看起来像这样: branch names changed to protect boss's reputation in the company

是否有"权利"修复历史的方法,以便它只显示一个合并提交,我的origin / pl / EngATSDataOnChkPrint分支到origin / master?我怀疑它会涉及某种git rebase -i和一些壁球,但是我在没有先得到一些建议的情况下尝试这样的事情我感到很疲倦(我更好在git而不是我的老板,但不是很多......)

谢谢!

2 个答案:

答案 0 :(得分:2)

TL; DR版本:你可以清理它,但你可能不应该这样做,因为太多人可能已经依赖于混乱。如果它只有两个人,那可能不是太多;那部分是你必须决定的(最好是与他们一起)。

这些提交已经发布,你和其他几个人已经发布了它们(我们至少知道两个,即你和你的老板)。

可以重做所有内容以减少合并或不合并,但是如果你这样做,任何已经选择合并的人都必须做一些工作来调整他们的存储库也是如此。原因很简单:git只有将新东西添加到存储库中,它实际上从未删除任何内容。 1

因此,您可以git reset使用"丢弃"一些合并,然后创建新的,但你的存储库仍然有原始的合并......任何选择它们的人,仍然有它们,可能已经完成了工作这取决于他们。如果是这样,他们会在将他们的工作与您认为已删除的内容(但他们仍然拥有)合并时重新引入这些提交,这意味着他们需要知道 not 将他们的工作与您的排序合并但是没有真正删除的工作。

具体来说,他们需要 rebase 他们在旧作品上的工作,或者你已经放置的新替代品,无论哪种情况发生在他们身上。< / p>

如果您选择在删除这些合并之后或作为删除这些合并的一部分来重新定义您的工作,也是如此。 (通常rebase丢弃合并。)这是因为rebase通过复制旧提交到新的提交,使用新ID和新的父ID。

例如,假设您有三次提交,并且您想要移动(重新绑定)它们。第一个&#34;移动&#34;必须复制commit才能使其具有新的父ID,并为其提供自己的新ID。这意味着还必须复制第二个提交,以便它可以将第一个副本的新ID作为其父ID,并为第二个副本提供新ID。然后必须复制第三个提交,以便它可以将第二个新ID作为其父ID:

(前):

... <- o <- o <- o     <-- master
        \
         o <- o <- o   <-- yourbranch

(复制后):

... <- o <- o <- o               <-- master
        \         \
         \         o <- o <- o   <-- yourbranch [copies]
          \
           o <- o <- o          [abandoned originals]

如果其他人没有这些提交 - 如果他们发布肯定是正确的 - 那么复制它们并忘记原始ID就没问题了。但是,如果其他人有原件,他们可能会重新介绍它们。

1 什么,从不?

不,永远不会!

什么,从来没有?

好吧,几乎没有!

(更确切地说,出现要移除的东西通常只是隐藏起来,它会保留30天左右,直到git决定它已经足够长时间才真正将其作为垃圾回收。 )

答案 1 :(得分:0)

rebase通常会删除merge-commits,因为rebased提交是线性的,不需要合并。只要尝试查看结果,如果出现问题就可以使用reflogreset撤消不良实验。

事情是,似乎历史已经被推入公共存储库(原点),所以在这种情况下你必须做一个通常对公共历史不利的强制推动。如果我是你,我会保持原样。历史看起来很奇怪,但也不错。