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

成功改组后是否仍需要合并？

简洁版本

• 合并将所有更改合并到一个分支中，并在一次提交中将它们合并到另一个分支中。
• Rebase说我希望分支的位置移动到新的起点

那你什么时候用哪一个呢？

合并

• 假设您已经创建了一个分支，以开发单个功能。当您希望将这些更改重新掌握时，您可能需要合并（您不必关心维护所有临时提交）。

变基

• 第二种情况是，如果您开始进行一些开发，然后另一位开发人员进行了不相关的更改。你可能想拉，然后重订到从资源库中的当前版本为基础修改。

这很简单。使用rebase，您说要使用另一个分支作为工作的新基础。

例如，如果有一个branch master，则创建一个分支来实现新功能，并说出它的名字cool-feature，当然master分支是新功能的基础。

现在，您要在某个点上添加您在master分支中实现的新功能。您可以只切换master并合并cool-feature分支：

$ git checkout master
$ git merge cool-feature

但是这样就添加了一个新的虚拟提交。如果您想避免意大利面的历史，可以重新设置基准：

$ git checkout cool-feature
$ git rebase master

然后合并到master：

$ git checkout master
$ git merge cool-feature

这次，由于主题分支具有相同的master提交以及具有新功能的提交，因此合并将是一种快速的方式。

为了补充TSamper提到的我自己的答案，

• 在合并之前，进行rebase通常是一个好主意，因为该主意是您将要合并的分支Y的工作集成到分支中B。
  但同样，合并之前，你解决任何冲突的分支（即：“重订”，如“重播我在我的分支工作从分支最近的点开始B）。
  如果做得正确的话，以后的合并从你的分支分支B可以快进。

• 合并会直接影响目标分支B，这意味着合并最好是微不足道的，否则合并B可能很长才能恢复到稳定状态（解决所有冲突的时间）

重组后的合并点？

在我所描述的情况下，我重新建立B了分支机构，只是有机会从上一个较近的位置重播我的工作B，而又留在了分支机构中。
在这种情况下，仍然需要合并以将我的“重播”作品带入B。

另一种情况（例如，在Git Ready中进行了描述）是B通过重新部署直接保存您的工作（这确实保存了所有不错的提交，甚至为您提供了通过交互式重新部署重新排序它们的机会）。
在那种情况下（当您在B分支中时变基），您是对的：不需要进一步的合并：

当我们没有合并或重新建立基础时，默认情况下是一个Git树

我们通过重新定级得到：

第二种情况是关于：如何使新功能重新掌握。

通过描述第一个rebase场景，我的意思是提醒大家，rebase也可以用作此操作的第一步（即“将新功能重新掌握”）。
您可以使用rebase首先将主节点“引入”新功能分支：rebase将重播来自的新功能提交HEAD master，但仍在newfeature分支中，从而有效地将分支起点从旧的主提交移至HEAD-master。
这让你解决任何冲突的分支（意思是，在隔离，同时允许主继续同步发展，如果你的解决冲突的阶段时间过长）。
然后，你可以切换到主和合并new-feature（或重订new-feature到master，如果你想保留做你的提交new-feature 科）。

所以：

• “ rebase vs. merge”可以看作是导入工作的两种方式master。
• 但是“先合并然后合并”可能是一个有效的工作流程，可以首先隔离解决冲突，然后恢复工作。

TL; DR

如有疑问，请使用合并。

简短答案

重新设置和合并之间的唯一区别是：

• 历史记录的结果树结构（通常仅在查看提交图时才注意到）是不同的（一个将具有分支，另一个将不具有分支）。
• 合并通常会创建一个额外的提交（例如，树中的节点）。
• 合并和变基将以不同方式处理冲突。Rebase将一次提交一次冲突，而一次合并将一次提交所有冲突。

因此，简短的答案是根据您希望历史记录的样子选择变基或合并。

长答案

选择要使用的操作时，应考虑一些因素。

您正在与其他团队（例如，开源，公共）开发人员共享更改的分支吗？

如果是这样，请不要重新设置基准。Rebase破坏了分支，除非使用，否则这些开发人员将拥有损坏/不一致的存储库git pull --rebase。这是快速使其他开发人员感到沮丧的好方法。

您的开发团队有多熟练？

变基是一种破坏性操作。这意味着，如果未正确应用它，则可能会丢失已完成的工作和/或破坏其他开发人员存储库的一致性。

我曾在团队中工作，开发人员全部来自公司可以聘请专门人员处理分支和合并的时代。这些开发人员对Git并不了解很多，也不想了解太多。在这些团队中，我不会因为任何原因而建议重新定级。

分支本身是否代表有用的信息

一些团队使用每个功能的分支模型，其中每个分支代表一个功能（或错误修正或子功能等）。在此模型中，该分支有助于标识相关的提交集。例如，可以通过还原该分支的合并来快速还原功能（公平地说，这是一种罕见的操作）。或通过比较两个分支来比较特征（更常见）。重新设置基准将破坏分支，这将不是直接的。

我也曾在使用每个开发人员分支模型的团队中工作（我们都去过那里）。在这种情况下，分支本身不会传达任何其他信息（提交已经具有作者）。重新部署不会有任何危害。

您可能出于任何原因想要还原合并吗？

与还原合并相比，还原（如撤消）还原非常困难和/或不可能（如果还原有冲突）。如果您认为有机会恢复，请使用合并。

您是否在团队中工作？如果是这样，您是否愿意对该分支机构采取全有或全无的方法？

需要使用相应的来拉基础操作git pull --rebase。如果您是自己工作，则可以记住在适当的时间应该使用哪种工具。如果您在团队中工作，这将很难协调。这就是为什么大多数变基工作流都建议对所有合并（和git pull --rebase所有提取）使用变基。

常见的神话

合并破坏历史记录（南瓜提交）

假设您有以下合并：

    B -- C
   /      \
  A--------D

有人会指出，合并会“破坏”提交历史记录，因为如果仅查看master分支（A-D）的日志，则会错过B和C中包含的重要提交消息。

如果这是真的，我们就不会有这样的问题。基本上，您将看到B和C，除非您明确要求不看它们（使用--first-parent）。自己尝试很容易。

变基允许更安全/更简单的合并

两种方法的合并方式不同，但是尚不清楚哪种方法总是比另一种更好，并且这可能取决于开发人员的工作流程。例如，如果开发人员倾向于定期提交（例如，他们每天从工作到家中进行两次提交），那么对于给定的分支可能会有很多提交。这些提交中的许多看起来可能都不像最终产品（我倾向于对每个功能重构一次或两次）。如果其他人正在处理相关的代码领域，并且他们试图重新整理我的更改，那可能是一个相当繁琐的操作。

Rebase更酷/更性感/更专业

如果您想将别名别名rm为rm -rf“节省时间”，那么也许适合您。

我的两分钱

我一直认为，总有一天，我会遇到一个场景，其中Git rebase是解决问题的出色工具。就像我认为我会遇到一种情况，其中Git reflog是一个很好的工具，可以解决我的问题。我已经与Git合作超过五年了。没发生

乱七八糟的历史从来就不是我真正的问题。我从来没有像一部激动人心的小说那样阅读我的提交历史。在大多数情况下，我需要历史记录，无论如何我都会使用Git责备或Git对分。在那种情况下，进行合并提交实际上对我有用，因为如果合并引起了问题，那对我来说是有意义的信息。

更新（4/2017）

我不得不提一下，尽管我的一般建议仍然成立，但我个人还是对使用rebase感到软化。我最近与Angular 2 Material项目进行了很多互动。他们使用rebase来保持非常干净的提交历史记录。这使我可以非常轻松地查看是什么提交修复了给定的缺陷，以及该提交是否包含在发行版中。它是正确使用rebase的一个很好的例子。

这里有很多答案说，合并会将您的所有提交变成一个提交，因此建议使用rebase保留您的提交。这是不正确的。这是一个坏主意，如果您已经推送了您的提交。

合并并不能抹杀你的提交。合并保存历史！（仅查看​​gitk）Rebase重写了历史记录，这在您按下后是一件坏事。

使用合并-不重新设置基准在您已经推送时。

这是Linus（Git的作者）的看法（现在托管在我自己的博客上，由Wayback Machine恢复））。这真是一本好书。

或者，您可以在下面阅读我自己的相同想法版本。

在master上重新分支：

• 提供了关于如何创建提交的错误想法
• 用一堆可能没有经过良好测试的中间提交来污染主机
• 实际上，由于在原始主题分支的创建时间与基础主题重新建立之间进行了更改，因此实际上可能会对这些中间提交造成构建中断。
• 很难找到主人结帐的好地方。
• 使提交的时间戳记与树中的时间顺序不符。因此，您将看到提交A在主机中的提交B之前，但是提交B是第一个编写的。（什么？！）
• 产生更多的冲突，因为在主题分支中的每个提交都可能涉及必须单独解决的合并冲突（有关每个提交中发生的事情的历史进一步卧底）。
• 是对历史的重写。如果要重设分支的分支已被推送到任何地方（与您以外的任何人共享），则自从您重写历史以来，您就已经搞砸了拥有该分支的其他所有人。

相反，将主题分支合并到master：

• 保留有关主题分支创建位置的历史记录，包括从master到topic分支的任何合并以帮助使其保持最新状态。您确实可以准确地了解开发人员在构建时使用的代码。
• master是一个主要由合并组成的分支，每个合并提交通常都是历史上的“好点”，可以安全地进行检查，因为这是可以集成主题分支的地方。
• 保留了该主题分支的所有单个提交，包括它们在主题分支中的事实，因此隔离这些更改是很自然的，您可以在需要的地方进行钻取。
• 合并冲突仅需解决一次（在合并时），因此在主题分支中进行的中间提交更改不必独立解决。
• 可以顺利完成多次。如果您将主题分支定期集成到母版中，那么人们可以继续建立在该主题分支上，并且可以继续独立合并。

TLDR：这取决于最重要的部分-整洁的历史或对发展顺序的真实表示

如果整洁的历史记录最重要，那么您首先需要重新设置基础，然后合并所做的更改，因此很清楚新代码是什么。如果您已经推动了分支机构，那么除非可以处理后果，否则不要重新建立基础。

如果最重要的是顺序的真实表示，那么您无需合并即可合并。

合并意味着：创建一个新的提交，将我的更改合并到目标中。注意：此新提交将具有两个父级-您的提交字符串中的最新提交以及您要合并的另一个分支的最新提交。

Rebase的意思是：使用我当前的提交集作为提示，创建一个全新的提交系列。换句话说，计算一下如果我从我的基础上开始进行更改，我将会看到什么样的更改。因此，在重新设置基准之后，您可能需要重新测试所做的更改，并且在重新基准设置期间，您可能会遇到一些冲突。

鉴于此，您为什么要重新定基？只是为了保持发展历史清晰。假设您正在使用功能X，并在完成后将更改合并到其中。目标现在将具有一个提交，该提交将沿“添加的功能X”的内容进行说明。现在，如果不进行合并，而是先进行基础合并再合并，则目标开发历史记录将在单个逻辑进程中包含所有单个提交。这样一来，以后审查更改就变得容易得多。想象一下，如果50名开发人员一直在合并各种功能，那么很难回顾一下开发历史。

也就是说，如果您已经将要处理的分支推送到上游，则不应该重新设置基础，而应该合并。对于尚未推送到上游的分支，请进行基础，测试和合并。

另一个可能需要重新设置基准的时间是，您希望在推向上游之前摆脱分支的提交。例如：提早引入一些调试代码的提交，以及其他进一步清理代码的提交。唯一的方法是执行交互式变基：git rebase -i <branch/commit/tag>

更新：当您使用Git连接到不支持非线性历史记录的版本控制系统（例如Subversion）时，您还希望使用rebase 。当使用git-svn桥时，非常重要的一点是，合并回Subversion的更改是中继的最新更改之上的顺序更改列表。只有两种方法可以做到：（1）手动重新创建更改；（2）使用rebase命令，这要快得多。

更新2：另一种思考变基的方法是，它可以实现从开发样式到要提交的存储库中接受的样式的某种映射。假设您喜欢以很小的小块来提交。您可以进行一次提交来解决打字错误，一次提交可以摆脱未使用的代码，依此类推。当您完成需要做的工作时，您将进行一系列的提交。现在，假设您要提交的存储库鼓励进行较大的提交，因此对于您正在执行的工作，人们可能希望进行一次或两次提交。您如何获取提交字符串并将其压缩到期望的值？您将使用交互式基准，并将您的微小提交压缩为更少的较大块。如果需要反向操作，也是如此-如果您的样式是一些大型提交，但是存储库需要一长串的小型提交。您也可以使用rebase来做到这一点。如果已合并，则现在将提交样式嫁接到主存储库中。如果有很多开发人员，您可以想象一段时间后要遵循几种不同的提交样式的历史记录会多么困难。

更新3：Does one still need to merge after a successful rebase?是的，您知道。原因是重新设置本质上涉及提交的“转移”。就像我上面说的，这些提交是经过计算的，但是如果从分支的角度来看有14个提交，那么假设您的rebase没有任何问题，那么之后（在重新设置基准之前）将有14个提交重新设置完成。在重新设置基准之前，您有一个分支。之后，您将具有相同长度的分支。在发布更改之前，您仍然需要合并。换句话说，根据需要进行多次变基（同样，仅当您尚未将更改推送到上游时）。仅在重新设置基准后才合并。

虽然合并无疑是集成更改的最简单，最常见的方法，但它并不是唯一的方法：Rebase是替代的集成方法。

了解合并会更好

当Git执行合并时，它将查找三个提交：

• （1）共同祖先犯。如果您遵循一个项目中两个分支的历史，则它们总是至少有一个共同的提交：此时，两个分支的内容相同，然后演变的方式也不同。
• （2）+（3）每个分支的端点。集成的目标是合并两个分支的当前状态。因此，它们各自的最新修订版特别受关注。将这三个提交组合在一起将实现我们所期望的集成。

快进或合并提交

在非常简单的情况下，两个分支之一自分支发生以来就没有任何新提交-它的最新提交仍然是共同的祖先。

在这种情况下，执行集成非常简单：Git可以将其他分支的所有提交添加到公共祖先提交之上。在Git中，这种最简单的集成形式称为“快进”合并。然后，两个分支共享完全相同的历史记录。

但是，在很多情况下，两个分支机构都各自向前移动。

为了进行集成，Git必须创建一个包含它们之间差异的新提交-合并提交。

人类承诺与合并承诺

通常，提交是由人类精心创建的。这是一个有意义的单元，它仅包装相关的更改并用注释对其进行注释。

合并提交有点不同：它不是由开发人员创建的，而是由Git自动创建的。与其包装一组相关的更改，它的目的是像打结一样连接两个分支。如果以后要了解合并操作，则需要查看两个分支的历史以及相应的提交图。

与Rebase集成

有些人更喜欢没有这种自动合并提交。相反，他们希望项目的历史看起来像是沿着一条直线发展的。没有迹象表明它在某个时刻被拆分为多个分支。

让我们逐步完成一个变基操作。该场景与前面的示例相同：我们希望将分支B的更改集成到分支A，但现在要使用rebase。

我们将分三步进行

1. git rebase branch-A // Synchronises the history with branch-A
2. git checkout branch-A // Change the current branch to branch-A
3. git merge branch-B // Merge/take the changes from branch-B to branch-A

首先，Git将“撤消”分支A上行开始分支之后（公共祖先提交之后）发生的所有提交。但是，当然，它不会丢弃它们：相反，您可以将这些提交视为“暂时保存”。

接下来，它将应用我们要集成的分支B的提交。此时，两个分支看起来完全相同。

在最后一步中，现在重新应用分支A上的新提交-但是在分支B的集成提交之上的新位置上（它们是基于新提交的）。

结果似乎是直线发展了。保留了原来的提交结构，而不是包含所有合并更改的合并提交。

最后，您将获得一个干净的分支branch-A，并且没有不需要的和自动生成的提交。

注：从真棒摘自后通过git-tower。该缺点的rebase也是在同一职位读好。

合并/变基之前：

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

之后git merge master：

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

之后git rebase master：

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

（A，B，C，D，E和F为提交）

该示例以及有关Git的详细说明可以在《Git基础教程》中找到。

这句话得到它：

总的来说，两全其美的方法是重新整理您所做的但尚未共享的本地更改，然后再推送它们以清理故事，但永远不要重新整理已推送到任何地方的内容。

资料来源：3.6 Git分支-变基，变基与合并

这个答案围绕Git Flow展开。这些表是使用漂亮的ASCII表生成器生成的，而历史树则使用此命令（别名为git lg）：

git log --graph --abbrev-commit --decorate --date=format:'%Y-%m-%d %H:%M:%S' --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%ad%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)'

表按时间倒序排列，以便与历史记录树更加一致。另请参阅git merge和之间的区别git merge --no-ff（您通常希望使用git merge --no-ff它，因为这会使您的历史看起来更接近现实）：

git merge

命令：

Time          Branch "develop"             Branch "features/foo"
------- ------------------------------ -------------------------------
15:04   git merge features/foo
15:03                                  git commit -m "Third commit"
15:02                                  git commit -m "Second commit"
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

结果：

* 142a74a - YYYY-MM-DD 15:03:00 (XX minutes ago) (HEAD -> develop, features/foo)
|           Third commit - Christophe
* 00d848c - YYYY-MM-DD 15:02:00 (XX minutes ago)
|           Second commit - Christophe
* 298e9c5 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git merge --no-ff

命令：

Time           Branch "develop"              Branch "features/foo"
------- -------------------------------- -------------------------------
15:04   git merge --no-ff features/foo
15:03                                    git commit -m "Third commit"
15:02                                    git commit -m "Second commit"
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

结果：

*   1140d8c - YYYY-MM-DD 15:04:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/foo' - Christophe
| * 69f4a7a - YYYY-MM-DD 15:03:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * 2973183 - YYYY-MM-DD 15:02:00 (XX minutes ago)
|/            Second commit - Christophe
* c173472 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git merge 与 git rebase

第一点：始终将功能合并到开发中，永远不要从功能中重新建立开发基础。这是重新定购黄金法则的结果：

的黄金法则git rebase是永远不要在公共分支上使用它。

换句话说：

切勿使您推送到任何地方的内容变基。

我个人要补充：除非是功能分支，并且您和您的团队都知道后果。

因此，git mergevs 问题git rebase几乎仅适用于要素分支（在以下示例中，--no-ff合并时始终使用它）。请注意，由于我不确定是否有更好的解决方案（存在争论），因此我仅提供两种命令的行为方式。就我而言，我更喜欢使用git rebase它，因为它会产生更好的历史树:)

在要素分支之间

git merge

命令：

Time           Branch "develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- --------------------------------
15:10   git merge --no-ff features/bar
15:09   git merge --no-ff features/foo
15:08                                                                    git commit -m "Sixth commit"
15:07                                                                    git merge --no-ff features/foo
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

结果：

*   c0a3b89 - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 37e933e - YYYY-MM-DD 15:08:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| *   eb5e657 - YYYY-MM-DD 15:07:00 (XX minutes ago)
| |\            Merge branch 'features/foo' into features/bar - Christophe
| * | 2e4086f - YYYY-MM-DD 15:06:00 (XX minutes ago)
| | |           Fifth commit - Christophe
| * | 31e3a60 - YYYY-MM-DD 15:05:00 (XX minutes ago)
| | |           Fourth commit - Christophe
* | |   98b439f - YYYY-MM-DD 15:09:00 (XX minutes ago)
|\ \ \            Merge branch 'features/foo' - Christophe
| |/ /
|/| /
| |/
| * 6579c9c - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * 3f41d96 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/            Second commit - Christophe
* 14edc68 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git rebase

命令：

Time           Branch "develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- -------------------------------
15:10   git merge --no-ff features/bar
15:09   git merge --no-ff features/foo
15:08                                                                    git commit -m "Sixth commit"
15:07                                                                    git rebase features/foo
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

结果：

*   7a99663 - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 708347a - YYYY-MM-DD 15:08:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| * 949ae73 - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * 108b4c7 - YYYY-MM-DD 15:05:00 (XX minutes ago)
| |           Fourth commit - Christophe
* |   189de99 - YYYY-MM-DD 15:09:00 (XX minutes ago)
|\ \            Merge branch 'features/foo' - Christophe
| |/
| * 26835a0 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * a61dd08 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/            Second commit - Christophe
* ae6f5fc - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

从develop到要素分支

git merge

命令：

Time           Branch "develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- -------------------------------
15:10   git merge --no-ff features/bar
15:09                                                                    git commit -m "Sixth commit"
15:08                                                                    git merge --no-ff develop
15:07   git merge --no-ff features/foo
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

结果：

*   9e6311a - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 3ce9128 - YYYY-MM-DD 15:09:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| *   d0cd244 - YYYY-MM-DD 15:08:00 (XX minutes ago)
| |\            Merge branch 'develop' into features/bar - Christophe
| |/
|/|
* |   5bd5f70 - YYYY-MM-DD 15:07:00 (XX minutes ago)
|\ \            Merge branch 'features/foo' - Christophe
| * | 4ef3853 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| | |           Third commit - Christophe
| * | 3227253 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/ /            Second commit - Christophe
| * b5543a2 - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * 5e84b79 - YYYY-MM-DD 15:05:00 (XX minutes ago)
|/            Fourth commit - Christophe
* 2da6d8d - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git rebase

命令：

Time           Branch "develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- -------------------------------
15:10   git merge --no-ff features/bar
15:09                                                                    git commit -m "Sixth commit"
15:08                                                                    git rebase develop
15:07   git merge --no-ff features/foo
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

结果：

*   b0f6752 - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 621ad5b - YYYY-MM-DD 15:09:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| * 9cb1a16 - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * b8ddd19 - YYYY-MM-DD 15:05:00 (XX minutes ago)
|/            Fourth commit - Christophe
*   856433e - YYYY-MM-DD 15:07:00 (XX minutes ago)
|\            Merge branch 'features/foo' - Christophe
| * 694ac81 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * 5fd94d3 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/            Second commit - Christophe
* d01d589 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

旁注

git cherry-pick

当您只需要一个特定的提交时，这git cherry-pick是一个不错的解决方案（该-x选项在原始提交消息正文中附加了一行“ （从提交中选取的樱桃...） ”，因此通常使用它是一个好主意-git log <commit_sha1>查看它）：

命令：

Time           Branch "develop"              Branch "features/foo"                Branch "features/bar"
------- -------------------------------- ------------------------------- -----------------------------------------
15:10   git merge --no-ff features/bar
15:09   git merge --no-ff features/foo
15:08                                                                    git commit -m "Sixth commit"
15:07                                                                    git cherry-pick -x <second_commit_sha1>
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

结果：

*   50839cd - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 0cda99f - YYYY-MM-DD 15:08:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| * f7d6c47 - YYYY-MM-DD 15:03:00 (XX minutes ago)
| |           Second commit - Christophe
| * dd7d05a - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * d0d759b - YYYY-MM-DD 15:05:00 (XX minutes ago)
| |           Fourth commit - Christophe
* |   1a397c5 - YYYY-MM-DD 15:09:00 (XX minutes ago)
|\ \            Merge branch 'features/foo' - Christophe
| |/
|/|
| * 0600a72 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * f4c127a - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/            Second commit - Christophe
* 0cf894c - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git pull --rebase

我不确定我可以比Derek Gourlay更好地解释它...基本上，使用git pull --rebase代替git pull:)虽然本文中缺少的是，您可以默认启用它：

git config --global pull.rebase true

git rerere

再次，在这里很好地解释。简而言之，如果启用它，则不必再多次解决相同的冲突。

在临Git的书有上一个很好的解释基础重建页。

基本上，合并将需要两次提交并将其合并。

将在这两个基础上归还共同祖先，并将这些更改彼此相继应用。这使得历史更“干净”。

但是，当您改变基准时，您将放弃先前的提交并创建新的提交。因此，您永远不应为公共存储库建立基础。在存储库上工作的其他人会讨厌您。

仅出于这个原因，我几乎完全合并了。99％的时间我的分支差异不大，因此，如果有冲突，它只会出现在一两个地方。

Git rebase用于使历史记录清理器和存储库结构中的分支路径线性化。

它也可用于将您创建的分支保密，因为在重新建立基础并将更改推送到服务器后，如果删除分支，则不会有您在使用的分支的证据。因此，您的分支机构现在已成为您的本地事务。

重新设置基准之后，我们还摆脱了一个额外的提交，该提交用于查看我们是否进行了正常的合并。

是的，成功重新设置基准后，仍然需要进行合并，因为rebase命令只是将您的工作放在您在重新基准确定中提到的分支之上，例如master，并将分支的第一次提交作为master分支的直接后代。 。这意味着我们现在可以进行快速前向合并，以将更改从该分支引入到master分支。

如果您只是一个开发人员，则可以使用rebase而不是merge来获得清晰的历史记录

一些实际的例子，在某种程度上与Gerrit的大规模开发有关用于审阅和交付集成：

当我将功能分支提升到新的远程主服务器时，我会合并。这样可以进行最少的提升工作，并且很容易在gitk中跟踪功能开发的历史。

git fetch
git checkout origin/my_feature
git merge origin/master
git commit
git push origin HEAD:refs/for/my_feature

准备交付提交时合并。

git fetch
git checkout origin/master
git merge --squash origin/my_feature
git commit
git push origin HEAD:refs/for/master

当我的交付提交由于任何原因而失败集成时，我会重新设置基础，并且需要将其更新为新的远程主服务器。

git fetch
git fetch <gerrit link>
git checkout FETCH_HEAD
git rebase origin/master
git push origin HEAD:refs/for/master

很多时候都解释了什么是基础，什么是合并，但是什么时候应该使用呢？

什么时候应该使用变基？

• 当您尚未推动分支/没有其他人正在分支上时
• 您想要完整的历史记录
• 您要避免所有自动生成的“合并..”提交消息

随着Git变基更改历史记录。因此，当其他人在同一分支上工作时/如果已推送它，则不应使用它。但是，如果您有本地分支机构，则可以在合并分支机构到母版之前进行合并变迁母版，以保留更清晰的历史记录。这样做，合并到master分支后，您将不会看到您在master分支中使用了分支-历史记录比较“干净”，因为您没有自动生成的“ merged ..”，但仍然有没有自动生成的“合并..”提交的主分支中的完整历史记录。

但是请确保使用git merge feature-branch --ff-only，以确保在将功能合并回main时创建单个提交时没有冲突。如果您在获取功能分支的历史记录时正在处理的每个任务都使用功能分支，而不是“合并..”提交，则这很有意思。

第二种情况是，如果您从一个分支分支，并且想知道主分支中发生了什么变化。Rebase为您提供了信息，因为它包括每个单次提交。

什么时候应该使用合并？

• 当您推动分支机构/其他人也在努力
• 您不需要完整的历史记录
• 简单地合并对您就足够了

当您不需要或不想在主分支中拥有某个功能分支的所有历史记录时，或者如果其他人正在同一分支上工作，则可以将其推送。如果您仍然想要历史记录，只需将master合并到Feature分支中，然后再将Feature分支合并到master中。这将导致快速合并，您在母版中拥有功能分支的历史记录（包括由于将母版合并到功能分支中而导致的合并提交）。

我git rebase什么时候使用？几乎永远不会，因为它会重写历史记录。git merge几乎总是首选，因为它尊重项目中实际发生的事情。