拉/推和分支后清理git历史记录没有冲突

Question

如何在进行更改后恢复线性历史记录，然后执行拉动（无冲突），然后执行/推送（创建人工分支和合并）。

有几个人在同一个分支上工作，但是在单独的文件/文件夹中。在提交之前，git有时会指示在提交之前必须从存储库中提取一些更改。在没有冲突的成功拉取之后，新代码被提交并推送。但是，git历史现在看起来像这样：

我希望历史是线性的，因为合并中没有冲突。在做了一些阅读之后，我明白如果没有冲突，我应该进行获取然后使用rebase来获得线性历史记录。但是契约已经完成了。如何恢复线性历史？

Answer 1

git rebase可行。假设当前分支为master，并且第一个图中的提交从底部到顶部标记。前4个绿色是A B C D，接下来的5个紫色是E F G H I，左边2个绿色是J K，右边2个紫色是L M，顶部绿色是N.

git rebase --onto J D master

我们得到线性历史A-B-C-D-J-E'-F'-G'-H'-I'-L'-M'。 E'和E是具有不同sha1的等效提交。

还有另一种方式

git rebase --onto I D master

我们得到一个线性历史A-B-C-D-E-F-G-H-I-J'-L'-M'。

如果git rebase不是那么清楚，也可以通过git reset和git cherry-pick来完成，前者要切割，后者要移植。

由于K和N是合并提交，因此它们不应存在于线性历史中。我们可以忽略它们。

git reset J --hard
git cherry-pick E F G H I L M
#or one by one: git cherry-pick E;git cherry-pick F;...

最后我们得到线性历史A-B-C-D-J-E'-F'-G'-H'-I'-L'-M'。

或以其他方式

git reset I --hard
git cherry-pick J L M

我们得到线性历史A-B-C-D-E-F-G-H-I-J'-L'-M'。如果没有冲突，这两棵树的内容相同。

Answer 2

merge（pull没有相应的配置或参数等于fetch + merge，您可以pull等于fetch + rebase但如果您想要或手动执行这些命令，如果合并是快进的话，仅将保持线性历史记录，这意味着您正在合并的分支没有唯一的提交。你也可以告诉merge只做合并，如果它是一个快进合并，或者告诉它永远不保持线性历史记录，而是总是创建一个合并提交。

rebase 始终维持线性历史记录。

是否存在冲突不会以任何方式影响历史线性。

如果您希望尽可能使用merge或rebase作为线性历史，则决定相对简单。

如果您的操作的目标分支是本地分支，意味着它上面没有任何唯一提交，您可以安全地执行rebase，因为它只会影响您的本地历史记录。

如果您的操作的目标分支已被推送，i。即有独特的提交已经被推动，因此最终被其他人提取，你应该使用merge并使用非线性历史记录，因为所有的同事都会讨厌你，因为每个人都必须构建如果他们已经将这些提交提交给你，那么这是一个非显而易见的反转。

对于您目前的情况也是如此，因为我知道您已经推动了合并的更改，这意味着如果您将其更改为线性历史记录，您将更改已发布的历史记录，并且所有同事都必须在您强制执行后重新定义其工作 - 推动你改变的历史。

如果你没有推动或者不关心会对你产生仇恨的浪潮，你可以轻松地进行变基调。如果你e。 G。从所有天鹅绒提交的底部开始进行第5次绿色提交是可以的，你可以简单地检查你的绿枝并做git rebase pink，你最终会得到线性历史。