建议何时使用Git rebase与Git merge?

成功重新创建数据库后,是否仍需要合并?


当前回答

在合并/重新基础之前:

A <- B <- C    [master]
^
 \
  D <- E       [branch]

git合并主机后:

A <- B <- C
^         ^
 \         \
  D <- E <- F

git rebase master之后:

A <- B <- C <- D' <- E'

(A、B、C、D、E和F为提交)

在Git基础教程中可以找到这个例子以及更多关于Git的详细信息。

其他回答

TLDR:这取决于什么是最重要的——整洁的历史还是发展顺序的真实再现

如果一个整洁的历史是最重要的,那么你会先重新基址,然后合并你的更改,所以很清楚新代码是什么。如果你已经推送了你的分支,除非你能够处理后果,否则不要重新基址。

如果序列的真实表示是最重要的,那么您可以合并而不重定基础。

合并意味着:创建一个新的提交,将我的更改合并到目标中。注意:这个新的提交将有两个父级:一个是提交字符串中的最新提交,另一个是合并的另一个分支的最新的提交。

Rebase的意思是:使用我当前的一组提交作为提示,创建一系列新的提交。换言之,计算一下如果我从重新基准点开始进行更改,我的更改会是什么样子。因此,在重新基准之后,您可能需要重新测试您的更改,并且在重新基准期间,您可能会发生一些冲突。

既然如此,你为什么要重新基准?只是为了保持发展历史的清晰。假设您正在处理功能X,当您完成后,将您的更改合并到中。目标现在将有一个单独的提交,该提交内容类似于“添加的功能X”。现在,如果您重新创建基础,然后进行合并,那么目标开发历史将包含单个逻辑进程中的所有单独提交,而不是合并。这使得以后查看更改更加容易。想象一下,如果50名开发人员一直在合并各种功能,那么你会发现很难回顾开发历史。

也就是说,如果您已经将正在处理的分支推到了上游,那么不应该重新创建基础,而应该合并。对于尚未向上游推送的分支,请重新基址、测试和合并。

另一次您可能需要重新设置基值,是在向上游推送之前从分支中删除提交。例如:早期引入一些调试代码的提交和进一步清理代码的提交。实现这一点的唯一方法是执行交互式rebase:gitrebase-i<branch/commit/tag>

更新:当您使用Git连接到不支持非线性历史的版本控制系统(例如Subversion)时,还需要使用rebase。在使用git-svn桥时,非常重要的是,您合并回Subversion的更改是主干中最新更改之上的一系列更改。只有两种方法可以做到这一点:(1)手动重新创建更改;(2)使用rebase命令,这要快得多。

更新2:另一种考虑rebase的方法是,它可以从您的开发风格映射到您提交的存储库中接受的风格。你有一次提交来修复拼写错误,一次提交去清除未使用的代码等等。当你完成你需要做的事情时,你有一系列的提交。现在让我们假设您提交的存储库鼓励大量提交,因此对于您正在进行的工作,可能需要一次或两次提交。如何获取提交字符串并将其压缩到预期值?你可以使用一个交互式的rebase,将你的小提交压缩成更少的大块。如果需要相反的方式,情况也是如此——如果您的风格是几个大的提交,但存储库需要长串的小提交。你也可以使用rebase来实现这一点。如果您进行了合并,那么现在已经将提交样式移植到了主存储库中。如果有很多开发人员,你可以想象一段时间后,用几种不同的提交样式来跟踪历史会有多困难。

更新3:成功重新创建数据库后,是否仍需要合并?是的,你是这样做的。原因是重基基本上涉及到提交的“转移”。如上所述,这些提交是经过计算的,但如果从分支点开始有14个提交,那么假设您的重基没有任何问题,那么在重基完成后,您将提前14个提交(在您重基的点之前)。你在重新开始之前有一个分支。之后将有一个相同长度的分支。您仍然需要在发布更改之前进行合并。换言之,尽可能多次地重新设置基准(同样,只有在您没有将更改推到上游的情况下)。仅在重新基准后合并。

简短版本

合并在一个分支中接受所有更改,并在一次提交中将它们合并到另一个分支。Rebase说我希望我的分支点转移到一个新的起点

那你什么时候用这两种?

合并

假设您创建了一个分支来开发单个功能。当您想将这些更改带回master时,可能需要合并。

回扣

第二种情况是,如果您开始进行一些开发,然后另一个开发人员进行了不相关的更改。您可能希望从存储库中提取并重新创建基础,以将当前版本的更改作为基础。

挤压:在这两种情况下都会保留所有提交(例如:“add feature”,然后是“typ”,然后“oops typ again”…)。通过挤压,可以将提交合并为单个提交。挤压可以作为合并或重基操作(--squash标志)的一部分完成,在这种情况下,通常称为挤压合并或挤压重基。

拉取请求:流行的git服务器(Bitbucket、GitLab、GitHub等)允许配置如何在每个回购基础上合并拉取请求。按照惯例,UI可能会显示“合并”按钮,但该按钮可以使用任何标志(关键字:合并、重基、挤压、快进)执行任何操作。

这很简单。使用rebase时,您可以使用另一个分支作为工作的新基础。

例如,如果您有一个分支主节点,您可以创建一个分支来实现一个新特性,并将其命名为酷特性,当然,主分支是新特性的基础。

现在,在某一点上,您希望添加在主分支中实现的新特性。您可以切换到master并合并酷功能分支:

$ git checkout master
$ git merge cool-feature

但这样就添加了一个新的虚拟提交。如果你想避免意大利面条的历史,你可以重新设定基准:

$ git checkout cool-feature
$ git rebase master

然后将其合并到master中:

$ git checkout master
$ git merge cool-feature

这一次,由于主题分支具有与master相同的提交,再加上具有新特性的提交,因此合并将是一个快速前进。

Gitrebase用于使历史中的分支路径更清晰,存储库结构更线性。

它还用于将您创建的分支保持为私有,因为在重新创建基础并将更改推送到服务器之后,如果您删除了分支,则不会有您曾处理过的分支的证据。因此,您的分支现在是您的本地关注点。

在进行重新基化之后,我们还消除了一个额外的提交,这是我们用来查看是否进行正常合并的。

是的,在成功的rebase之后仍然需要进行合并,因为rebase命令只是将您的工作放在您在rebase过程中提到的分支之上,比如master,并将分支的第一次提交作为master分支的直接后代。这意味着我们现在可以进行快速合并,将更改从该分支带到主分支。

Pro Git的书在重新设置基础页面上有一个很好的解释。

基本上,合并将进行两次提交并合并它们。

一个重基将转到这两者的共同祖先,并在彼此之上逐步应用更改。这使得历史更加“清晰”和线性。

但当您重新创建基准时,您将放弃以前的提交并创建新的提交。因此,您永远不应该重新设置公共存储库的基础。其他在存储库中工作的人会恨你。

仅出于这个原因,我几乎完全合并了。99%的时候,我的分支机构没有太大的差异,所以如果有冲突,只会发生在一两个地方。