GitRebase与Merge：您应该使用哪一个？

Git rebase 命令将一个分支移动到另一个分支头部的新位置。与 Git 合并命令不同， rebase 涉及重写项目历史记录。这是一个很棒的工具，但不要 rebase 其他开发人员基于其工作的提交。
Gitrebase命令将两个源代码分支合并为一个。Gitmerge命令也这样做。我们解释了rebase它的作用、使用方式以及何时使用merge 。

文章插图
Git 爆炸式增长
由于对其他版本控制系统及其缓慢的更新和提交感到沮丧，以 Linux 内核闻名的Linus Torvalds在 2005 年抽出一个月的时间来编写自己的版本。他将其命名为 Git 。
GitHub、 GitLab和 BitBucket等站点已经共生地促进了 Git 并从中受益。今天 Git 在全球范围内使用，在 2022 年的一项调查中， 71,000 名受访者中有 98% 使用 Git 作为版本控制系统。
Git 的主要设计决策之一是速度。特别是，与分支机构的合作必须尽可能快。分支是版本控制系统的基本组成部分。项目存储库将有一个主分支或主分支。这是项目代码库所在的位置。诸如新功能之类的开发在隔离的侧分支中进行。这可以防止在分支中完成的工作弄乱主分支，并且允许在代码库的不同部分同时进行开发。
随着侧分支中的开发完成，通过将开发分支合并到主分支，将更改转移到主分支。在其他版本控制系统中，使用分支是困难的，而且计算量大。在 Git 中使用分支非常快，而且非常轻量级。在其他系统中曾经是乏味且经常避免的练习，在 Git 中变得微不足道。
Gitrebase命令是将更改从一个分支转移到另一个分支的另一种方法。merge和命令具有相似的rebase目标，但它们以不同的方式实现其目的并产生略有不同的结果。
什么是 Git 合并？
那么Gitmerge命令是做什么用的呢？假设您创建了一个分支dev-branch来处理一项新功能。
您进行了一些提交，并测试了您的新功能。一切正常。现在您想将新功能发送到master分支机构。您必须在master分支中才能将另一个合并到它。
master 我们可以通过在合并之前明确检查它来确保我们在分支中。
我们merge已经为我们完成了。如果您签出master分支并编译它，它将具有新开发的功能。Git实际执行的是三向合并。master它比较和分支中的最新提交，以及创建之前分支dev-branch中的提交。然后它在分支上执行提交。masterdev-branchmaster
合并被认为是非破坏性的，因为它们不会删除任何内容，也不会更改任何 Git 历史记录。仍然存在，并且以前的dev-branch提交都没有改变。创建一个新的提交来捕获三向合并的结果。
合并后，我们的 Git 存储库看起来像一个时间线，其中有一条备用线分支，然后返回到主时间线。
分公司已dev-branch并入master分公司。
如果您在一个项目中有很多分支，项目的历史就会变得混乱。如果一个项目有很多贡献者，通常就是这种情况。因为开发工作分成许多不同的路径，所以开发历史是非线性的。如果分支有自己的分支，理清提交历史变得更加困难。
请注意，如果您在master分支中有未提交的更改，则需要先对这些更改执行一些操作，然后才能将任何内容合并到其中。您可以创建一个新分支并在那里提交更改，然后进行合并。然后，您需要将临时分支合并回主分支。
这行得通，但 Git 有一个命令可以实现同样的事情，而无需创建新的分支。该stash命令为您存储未提交的更改，并允许您使用stash pop.
Git Rebase 与 Merge：您应该使用哪一个？
这不是rebasevs.的情况merge 。它们都是功能强大的命令，您可能会同时使用它们。也就是说，有些用例rebase并不能很好地工作。由错误使用引起的merge拆包错误令人不快，而由错误引起的拆包错误rebase是地狱般的。
rebase如果您是唯一使用存储库的开发人员，那么您做一些灾难性的事情的可能性就会降低。例如，您仍然可能rebase在错误的方向上，并且rebase您的 master 分支到您的new-feature分支上。要取回您的master分支机构，您需要rebase再次这样做，这次是从您的new-feature分支机构到您的master分支机构。这将恢复您的master分支，尽管历史看起来很奇怪。
不要rebase在其他人可能工作的共享分支上使用。当您将重新设置基础的代码推送到远程存储库时，您对存储库的更改会给很多人带来问题。
【GitRebase与Merge：您应该使用哪一个？】如果您的项目有多个贡献者，安全的做法是只rebase在您的本地存储库上使用，而不是在公共分支上使用。同样，如果拉取请求构成代码审查的一部分，请不要使用rebase. 或者至少，不要rebase在创建拉取请求后使用。其他开发人员可能正在查看您的提交，这意味着这些更改位于公共分支上，即使它们不在该master分支上。
危险在于您要rebase提交已经推送到远程存储库的提交，而其他开发人员可能已经基于这些提交进行了工作。您的本地rebase将使那些现有的提交消失。如果您将这些更改推送到存储库，您将不会受到欢迎。
其他贡献者将不得不经历一场混乱merge才能将他们的工作推回存储库。如果您随后将他们的更改拉回到您的本地存储库，您将面临取消挑选一堆重复更改的麻烦。
Rebase在你的项目中可能是非法的。可能存在当地的文化异议。一些项目或组织认为rebase这是一种异端和亵渎行为。有些人认为 Git 历史应该是不可侵犯的、永久的记录所发生的事情。所以， rebase可能不在讨论范围内。
但是，在本地，在私人分支机构上使用， rebase是一个有用的工具。
在你 rebase之后推送，并将它限制在你是唯一开发人员的分支上。或者至少，所有开发都已停止，并且没有其他人基于您分支机构的提交开展任何其他工作。