关于git merge和git rebase，有很多争论，哪个更好。今天，在关于Git Rebase vs Merge的博客中，我们将消除你对Git Rebase和Git Merge的所有疑惑。这两种技术的目的是一样的，所以要理解它们是有点困难的，因为它们有相似之处。 在博客的最后，你会知道什么时候使用Git Rebase vs Merge。
Git Merge和Git Rebase命令是用来将多个开发者的工作合并到一个代码中的。这两个命令的最终目的是相同的，但它们的用法各不相同。今天在这篇博客中，我们将尝试理解Git Merge vs Git Rebase。
如果你不喜欢阅读，这里有一个关于Git Rebase vs Merging的视频，它将帮助你理解本博客中的内容。
所以，以下是本博客所涉及的主题：
Git是如何工作的？
- 什么是提交？
- 什么是分支？
什么是合并？
Git合并？
Git Rebase?
Git Merge vs Git Rebase.
我们何时使用它们？
Git Rebase 和 Git Merge 如何一起使用？
总结
Git 是如何工作的？
要理解git的工作，我们需要理解git的两个基本概念，即git commit和git branch。让我们分别来理解这两个术语。
什么是提交？
提交被定义为存储代码和其变化的位置。让我们举个例子，从下面的图中简单讨论一下：
图 1: 所做的修改被保存在一个提交中
在图 1 中，让我们假设我们有四个 python 文件。我们把它们保存在git上。这四个 Python 文件将被保存在一个提交中。每个提交都有一个commit-id，在我们的例子中是1234。现在让我们假设我们对代码做了一些修改，增加了另一个python文件。这些改动在 git 中会被保存为另一个提交，提交号为 14343。这可以在图 2 中看到。所以每当我们做任何改动，都会产生一个新的提交。
图 2: 仓库中的修改将被保存为新的提交，并有一个新的提交标识。
什么是分支？
分支是不同版本的代码的代表。让我们举个例子来理解，假设你有一个正在运行的网站。这个网站看起来是这样的。
图3：网站修改前的例子
你想给这个网站增加更多的功能。为此，你将不得不改变网站的代码。但是，如果你改变了代码，你不希望这些改变反映在已经部署的主网站上。那么，你会怎么做？理想情况下，你会把这个网站的代码复制到一个新的文件夹中。在代码中进行修改，然后一旦修改完成，你将替换主文件夹中的代码，对吗？让我们了解一下，我们如何在git中做上述事情。
所以，在git中，为了隔离不同版本的代码，我们有分支。默认情况下，你的所有代码都存储在主分支上。所以，我们上面展示的网站就是主分支。现在，我们不想碰主分支的代码，我们想把主分支的代码复制到一个新的地方，在那里我们可以实验或修改代码。因此，不影响主分支。因此，我们从主分支创建一个新的分支，我们称它为 "特性分支"。现在，你在特性分支上做的任何新改动，都不会影响主干分支上的代码。
图 4：主分支和特性分支
完成修改后，我们只需将 "特性 "分支的修改 "合并 "到 "主分支"。现在，在特性分支上所做的修改也将存在于主干分支上。
图 5：特性分支与主干分支的合并
如果我们考虑上述网站的例子，合并后的变化可以在下面的图中看到。
图 6:将变化合并到主分支后，网站上的变化被描绘出来。
如果你不理解合并，不用担心，在下一节中一切都会清楚。
合并是什么意思？
一般来说，合并意味着将一些东西合并成一个单一的实体。
Git 合并是一种技术，用于将一个分支的修改纳入另一个分支。
因此，让我们以下图为例，它显示了两个分支（feature和master分支）合并前后的状态。蓝色提交在主分支，黄色提交在特性分支。
图 7:合并前
在图 7：合并前，我们可以看到主分支上有一些提交。我们在主干分支上提交了 "2 "之后，创建了一个特性分支。后来，我们在特性分支上做了一些修改，形式是提交 A 和 B，我们也在主干分支上做了一些修改，形式是提交 3。
在当前情况下，主干分支有提交 1、2 和 3 的代码，但没有功能分支的提交 A 和 B 的改动。
同样，由于特性分支是在提交 2 时从主干分支出来的，所以它有提交 1、2、A 和 B 的代码，但没有主干分支的提交 3 的代码。
下面，我们合并了主干上的特性分支，让我们了解一下发生了什么。
图 8: 合并后
我们合并了主干上的特性分支，产生了提交 4。主干上的提交4包含了所有代码的修改，即提交1、2、3、A和B。现在，我们了解了合并，让我们来了解在git中可以执行的不同类型的合并。在Git中，合并有两种类型：
-
Git 合并
-
Git 重置
让我们详细了解一下这两种类型
Git Merge
Git 合并是git中的一种合并技术，其中分支上的提交记录是完整的。
让我们举个例子，如果我们有一个项目，在主分支上有3个提交，分别是提交1、2、3，特征分支的提交是提交A和B。如果我们执行git合并操作，那么提交A和B将被合并为提交4到主分支。这就是图 9 所描述的。
图 9:Git 合并之前和之后。
优点：
日志非常详尽，可以帮助了解每次合并发生的完整历史
很容易发现错误并解决它们。
缺点：
git合并的主要缺点是它导致了一个笨拙的日志/历史。虽然，你现在可以追踪哪个代码变更来自哪个分支，以及在哪个时间点进行了变更。但是，版本库的历史并不十分友好。
图 10: 例子显示了一个有多个分支的仓库，使用 git-merge 进行了合并。
Git-Rebase
Git Rebase 与 git merge 相似，但该技术在合并后会修改日志。引入 Git Rebase 是为了克服合并的局限性，即让仓库历史的日志看起来是线性的。
让我们举个例子，如果我们有一个项目，主分支上有 3 个提交，分别是提交 1、2、3，特性分支上有提交 A 和 B，如果我们执行 git rebase 操作，那么提交 A 和 B 将被重新建立到主分支上，成为提交 4 和 5，特性分支上将没有日志。这在图 12 中有所描述。
图 12: git rebase 之前和之后
优点：
- 日志是线性的
- 很容易在项目中移动。
缺点是 ：
- 我们无法跟踪提交在目标分支上的时间和方式。
Git 合并 Vs Git 重置
| 合并 | 重置 |
| Git merge 是一个允许你从 Git 合并分支的命令。 | Git rebase 是一条允许开发者将一个分支的修改整合到另一个分支的命令。 |
| 在Git合并中，日志会显示提交合并的完整历史。 | 在Git rebase中，日志是线性的，因为提交被重新建立了 |
| 功能分支上的所有提交将被合并为主分支上的一个提交。 | 所有的提交都会被重基，并在主分支上添加相同数量的提交。 |
| 当目标分支是共享分支时，应使用 Git 合并 | 当目标分支是私有分支时，应使用Git Rebase。 |
让我们用一个例子来理解，请参考下图：什么时候使用Git Merge vs Git Rebase？
图 13 描述了 git merge 与 git rebase 后仓库的区别
在 git merge 中，看结尾的图，我们可以看出 Commit A 和 B 来自特性分支。然而，在 git-rebase 图中，我们很难理解提交 A 和 B 来自哪里。因此，当我们希望我们的团队能够以一种能够识别每个提交来自何处的方式来理解日志时，我们会进行git merge。当仓库的日志不会被其他人引用时，我们会使用 Git Rebase。总而言之，当我们在分支上工作时，我们可以使用Git Rebase，因为其他开发者无法看到。而当目标分支和源分支可以被其他开发者看到时，我们可以使用 Git 合并。
Git Rebase 和 Git Merge 如何结合使用？
让我们举个例子，如果我们有一个项目，其中有一个主分支，有 3 个提交，分别是 1、2、3，和 2 个特性分支，特性分支 1 上有提交 A、B，特性分支 2 上有提交 C、D，如图 14 所示。
图14：上述例子的表述
我们假设开发者 A 正在处理特性分支 1。
为了试验代码，他创建了另一个分支 Feature branch 2，在其中做了一些修改，并通过提交 C 和 D 最终完成。
他不想让别人知道他的私有分支，因为那是不必要的。所以，他可以在特性1上重新建立特性2。
现在，他终于可以把特性1的分支合并到主干上了，结果如下图所示：
上图是其他开发者看到的最终日志的样子。他们只能看到在特性1分支上的提交，然后在主干分支上合并，提交4。
至此，Git 合并与 Git 重置的博客就结束了。我们相信你对 Git 合并与 Git 重置的疑惑现在一定很清楚了。如果没有，我们建议你先了解一下Git的基础知识，请查看我们的Git教程博客以获得更多信息。
