Git rebase失去了历史，那么为什么要rebase？ [英] Git rebase loses history, then why rebase?

问题描述

在过去的几天里，我一直在考虑重组Git。大多数重新定义的论据都表明它清理了历史并使其更加线性。如果你做了简单的合并（例如），你会得到一个历史记录，显示历史发生什么变化以及何时将它们合并在一起。据我所知，重新贴牌可以消除所有的历史。问题是这样的：为什么你不希望回购历史记录反映出代码开发的所有方式，包括它在何处以及如何分歧？ 解决方案

>

据我所知，rebasing会删除所有历史记录。

这不正确。顾名思义，重定位会更改提交的基底。通常在该进程中不会有任何提交丢失（除非您没有得到合并提交）。尽管你关于如何在开发过程中保留所有开发过程的观点是正确的，但这经常会导致混淆历史。

特别是在与其他人合作时每个人都在自己的分支上工作，同时要求其他人的某些更改继续进行（例如，A要求B执行某些操作以便A可以在自己的开发中使用该功能），这会导致多次合并。例如像这样：

 ＃ - ＃ - ＃ - ＃ -  * ----- *  - --------------- * ---＃--- \分行B 
 / / / / \ 
 ---＃----- ＃-----＃-----＃-----＃-----＃-----＃-----＃----- *分支A 
  

在这个例子中，我们有一个分支在时间上分开工作，但不断从原始分支引入更改（＃是原始分支提交，*为合并）。

现在，如果我们在合并之前在分支B上进行重新绑定，那么我们可以得到以下结果：

 ＃ - ＃ - ＃ - ＃ - ＃--- \分行B 
 / \ 
  -  - ＃---＃---＃---＃---＃---＃---＃---＃--------------- *分支A 
  

这表示相同的实际更改，但B已重新分配给A上的某个较旧提交，因此所有B合并之前已经完成的工作不再需要（因为这些改变是无用的在那个较旧的提交中有ady）。现在缺少的所有提交都是合并，通常不包含有关开发过程的任何信息。 （请注意，在这个例子中，你也可以稍后重新绑定A上一次提交的内容，以获得一条直线，从而有效地移除对第二个分支的提示）。

I've been looking into rebasing with Git over the past couple days. Most of the arguments for rebasing say that it cleans up the history and makes it more linear. If you do plain merges (for example), you get a history that shows when the history diverged and when it was brought back together. As far as I can tell, rebasing removes all that history. Question is this: why wouldn't you want the repo history to reflect all the ways the code developed, including where and how it diverged?

解决方案

As far as I can tell, rebasing removes all that history.

That's not correct. Rebasing, as the name suggests, changes the base of commits. Usually no commit is lost in that process (except that you don't get a merge commit). While your argument about keeping really everything of the development process inside the history the way it was done is correct, very often this leads to confusing histories.

Especially when working with others that each work on their own branches while requiring certain changes from others to continue (for example A asks B to implement something so that A can use that feature in his own development), this leads to many merges. For example like this:

     #--#--#--#--*-----*-----------------*---#---\         Branch B
    /           /     /                 /         \
---#-----#-----#-----#-----#-----#-----#-----#-----*       Branch A

In this example we have a branch that works separately for the time but constantly pulls in changes from the original branch (# are original commits, * are merges).

Now if we do a rebase on Branch B before merging in back in, we could get the following:

                             #--#--#--#--#---\         Branch B
                            /                 \
---#---#---#---#---#---#---#---#---------------*       Branch A

This represents the same actual changes, but B was rebased to some older commit on A, so all merges on B that were done before are no longer needed (because those changes are already there in that older commit). And all commits that are missing now, are the merges, which usually do not contain any information about the development process. (Note that in this example you could also rebase that last commit on A later on, to get a straight line, effectively removing any hints to the second branch)

这篇关于Git rebase失去了历史，那么为什么要rebase？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！