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

这个答案广泛围绕GitFlow。这些表是用漂亮的ASCII表生成器生成的，历史树是用这个奇妙的命令（别名为gitlg）生成的：

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，因为它使您的历史看起来更接近现实）：

合并分支

命令：

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--无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合并vs git重基

第一点：总是将特性合并到开发中，而不是从特性重新基础开发。这是回扣黄金法则的结果：

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

换句话说：

永远不要把你推到某个地方的东西重新放在底座上。

我个人会补充一句：除非这是一个功能分支，并且您和您的团队意识到其后果。

因此，git merge与git rebase的问题几乎只适用于功能分支（在下面的示例中，合并时始终不使用ff）。注意，由于我不确定是否有更好的解决方案（存在争论），所以我只提供两个命令的行为方式。在我的例子中，我更喜欢使用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 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重基

命令：

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

从开发到功能分支

合并分支

命令：

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重基

命令：

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是一个很好的解决方案（-x选项在原始提交消息正文中附加一行“（cherry-picked from commit…）”，因此通常最好使用它-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--重新基数

我不确定我能比德里克·古尔利解释得更好。。。基本上，使用git pull--rebase而不是git pull:）但本文中缺少的是，您可以默认启用它：

git config --global pull.rebase true

吉特重读

再次，这里很好地解释了一下。但简单地说，如果您启用了它，您就不再需要多次解决同一冲突。

一些与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

这句话的意思是：

总的来说，实现两个世界的最佳效果的方法是重新定位本地在推送更改之前，您已进行但尚未共享的更改为了整理你的故事，但千万不要重复你推送的任何内容在某处

来源：3.6 Git分支-重新分类、重新分类与合并

虽然合并绝对是集成更改的最简单和最常见的方式，但它不是唯一的方式：Rebase是一种替代的集成方式。

更好地理解合并

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

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

快进或合并提交

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

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

然而，在很多情况下，这两个分支都各自向前移动。

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

人工提交和合并提交

通常，一个承诺是由一个人精心创造的。这是一个有意义的单元，它只包装相关的更改并用注释注释它们。

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

与Rebase集成

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

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

我们将分三步完成

git rebase branch-A//将历史与branch-A同步git checkout branch-A//将当前分支更改为branch-Agitmergebranch-B//合并/从branch-B到branch-A进行更改

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

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

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

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

最后，您得到了一个干净的分支分支a，没有不需要的和自动生成的提交。

注：摘自git tower的精彩帖子。在同一篇文章中，rebase的缺点也是一个很好的解读。

TL；博士

如果您有任何疑问，请使用merge。

简短回答

重新基准和合并之间的唯一区别是：

生成的历史树结构（通常只有在查看提交图时才明显）不同（一个有分支，另一个没有分支）。合并通常会创建一个额外的提交（例如树中的节点）。合并和重新基础将以不同的方式处理冲突。Rebase将一次提交一个冲突，而merge将一次显示所有冲突。

因此，简单的答案是根据您希望的历史外观选择重新基准或合并。

长答案

在选择要使用的操作时，需要考虑以下几个因素。

您从中获得更改的分支是否与团队之外的其他开发人员共享（例如，开源、公共）？

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

您的开发团队有多熟练？

回扣是一种破坏性操作。这意味着，如果不正确应用它，您可能会丢失已提交的工作和/或破坏其他开发人员存储库的一致性。

我曾在团队中工作过，这些团队中的开发人员都来自一个公司能够负担得起专门的员工来处理分支和合并的时代。这些开发人员对Git了解不多，也不想了解太多。在这些团队中，我不会因为任何原因而冒险建议重新定基。

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

一些团队使用每个功能的分支模型，其中每个分支表示一个功能（或错误修复或子功能等）。在这个模型中，分支帮助识别相关提交的集合。例如，可以通过恢复该分支的合并来快速恢复功能（公平地说，这是一个罕见的操作）。或者通过比较两个分支来区分一个特性（更常见）。Rebase会破坏分支，这并不简单。

我也曾在使用每个开发人员分支模型的团队中工作过（我们都去过）。在这种情况下，分支本身不传递任何附加信息（提交已经包含作者）。换基不会有什么害处。

是否出于任何原因要还原合并？

与恢复合并相比，恢复（如撤消）重基相当困难和/或不可能（如果重基发生冲突）。如果您认为有机会恢复，请使用merge。

你是团队成员吗？如果是的话，你愿意在这一分支机构采取“要么全有要么全无”的方法吗？

需要使用相应的git pull--Rebase来拉动Rebase操作。如果你是自己工作，你可能会记得在适当的时候应该使用哪一个。如果你在一个团队中工作，这将很难协调。这就是为什么大多数rebase工作流建议对所有合并使用rebase（以及git pull--rebase对所有合并）。

常见的神话

合并销毁历史记录（压缩提交）

假设您有以下合并：

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

有些人会说合并“破坏”了提交历史，因为如果只查看主分支（A-D）的日志，就会错过B和C中包含的重要提交消息。

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

Rebase允许更安全/更简单的合并

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

热巴更酷/更性感/更专业

如果您想将rm别名为rm-rf以“节省时间”，那么可能需要重新设置基准。

我的两美分

我一直认为有一天我会遇到这样一个场景，Git rebase是解决这个问题的绝佳工具。就像我认为我会遇到这样一个场景，Git reflog是一个很好的工具，可以解决我的问题。我已经在Git工作了五年多了。这还没有发生。

混乱的历史对我来说从来都不是一个问题。我从来没有像读一本令人兴奋的小说那样阅读我的承诺历史。大多数时候，我需要一段历史，无论如何，我都会使用Git责备或Git平分。在这种情况下，合并提交实际上对我很有用，因为如果合并引入了问题，那对我来说就是有意义的信息。

更新（2017年4月）

我觉得有义务提及我个人对使用rebase的态度有所软化，尽管我的一般建议仍然有效。我最近与Angular 2 Material项目进行了很多互动。他们使用rebase来保持非常干净的提交历史。这使我能够非常容易地看到是什么提交修复了给定的缺陷，以及该提交是否包含在发布中。它是正确使用rebase的一个很好的例子。