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

问题描述

过去几天我一直在研究使用 Git 进行变基.大多数关于 rebase 的论点都说它清理了历史并使其更加线性.如果您进行简单的合并(例如)，您会得到一个历史记录，显示历史何时发生分歧以及何时重新组合在一起.据我所知，变基会删除所有这些历史记录.问题是:你为什么不希望回购历史反映代码开发的所有方式，包括它在哪里以及如何分歧?

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?

推荐答案

据我所知，rebase 删除了所有这些历史记录.

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

这是不对的.顾名思义，rebase 改变了提交的 base.通常在该过程中不会丢失任何提交(除非您没有获得合并提交).虽然您关于将开发过程的所有内容真正保留在历史中的论点是正确的，但这通常会导致历史混乱.

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.

特别是当与其他人一起工作时，每个人都在自己的分支上工作，同时要求其他人的某些更改才能继续(例如，A 要求 B 实现一些东西，以便 A 可以在他自己的开发中使用该功能)，这会导致许多合并.例如像这样:

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).

现在，如果我们在重新合并之前对分支 B 进行 rebase，我们可以获得以下结果:

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

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

这代表了相同的实际更改，但 B 已重新基于 A 上的某个较旧提交，因此不再需要之前在 B 上完成的所有合并(因为这些更改已存在于该较旧提交中).现在缺少的所有提交都是合并，通常不包含有关开发过程的任何信息.(请注意，在此示例中，您还可以稍后将最后一次提交重新设置为 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屋！