by Vali Shah

通过瓦利沙阿

Git合并和Git变基简介：它们做什么以及何时使用它们 (An Introduction to Git Merge and Git Rebase: What They Do and When to Use Them)

As a Developer, many of us have to choose between Merge and Rebase. With all the references we get from the internet, everyone believes “Don’t use Rebase, it could cause serious problems.” Here I will explain what merge and rebase are, why you should (and shouldn’t) use them, and how to do so.

作为开发人员，我们许多人必须在“合并”和“重新设置”之间进行选择。 有了我们从互联网上获得的所有参考，每个人都认为“不要使用Rebase，它可能会导致严重的问题。” 在这里，我将解释什么是合并和变基，为什么(不应该)使用它们以及如何使用它们。

Git Merge and Git Rebase serve the same purpose. They are designed to integrate changes from multiple branches into one. Although the final goal is the same, those two methods achieve it in different ways, and it's helpful to know the difference as you become a better software developer.

Git Merge和Git Rebase的目的相同。 它们旨在将来自多个分支的更改集成到一个分支中。 尽管最终目标是相同的，但是这两种方法以不同的方式实现了目标，当您成为一名更好的软件开发人员时 ，了解两者之间的差异将很有帮助。

This question has split the Git community. Some believe you should always rebase and others that you should always merge. Each side has some convincing benefits.

这个问题分裂了Git社区。 有些人认为您应该始终调整基础，而另一些人则应该始终合并。 双方都有一些令人信服的好处。

Git合并 (Git Merge)

Merging is a common practice for developers using version control systems. Whether branches are created for testing, bug fixes, or other reasons, merging commits changes to another location. To be more specific, merging takes the contents of a source branch and integrates them with a target branch. In this process, only the target branch is changed. The source branch history remains the same.

对于使用版本控制系统的开发人员而言，合并是一种常见做法。 无论是出于测试，错误修复或其他原因而创建分支，都将合并更改提交到另一个位置。 更具体地说，合并采用源分支的内容，并将它们与目标分支集成在一起。 在此过程中，仅目标分支被更改。 源分支历史记录保持不变。

优点 (Pros)

• Simple and familiar简单又熟悉
• Preserves complete history and chronological order保留完整的历史记录和时间顺序
• Maintains the context of the branch维护分支的上下文

缺点 (Cons)

• Commit history can become polluted by lots of merge commits提交历史可能会被很多合并提交污染

• Debugging using git bisect can become harder

  使用git bisect进行调试可能会变得更加困难

怎么做 (How to do it)

Merge the master branch into the feature branch using the checkout and merge commands.

使用checkout和merge命令将master分支合并到feature分支。

$ git checkout feature
$ git merge master(or)$ git merge master feature

This will create a new “Merge commit” in the feature branch that holds the history of both branches.

这将在Feature分支中创建一个新的“ Merge commit ”，其中包含两个分支的历史记录。

Git Rebase (Git Rebase)

Rebase is another way to integrate changes from one branch to another. Rebase compresses all the changes into a single “patch.” Then it integrates the patch onto the target branch.

Rebase是将更改从一个分支集成到另一个分支的另一种方法。 Rebase将所有更改压缩到单个“补丁”中。 然后，它将补丁集成到目标分支上。

Unlike merging, rebasing flattens the history because it transfers the completed work from one branch to another. In the process, unwanted history is eliminated.

与合并不同，重新定基使历史变平，因为它将已完成的工作从一个分支转移到另一个分支。 在此过程中，消除了不需要的历史记录。

Rebases are how changes should pass from the top of the hierarchy downwards, and merges are how they flow back upwards

重新设置是更改应如何从层次结构的顶部向下传递，而合并则是更改如何向上传递的基础

优点 (Pros)

• Streamlines a potentially complex history简化潜在的复杂历史
• Manipulating a single commit is easy (e.g. reverting them)操作单个提交很容易(例如还原它们)
• Avoids merge commit “noise” in busy repos with busy branches避免在具有繁忙分支的繁忙存储库中合并提交“噪声”
• Cleans intermediate commits by making them a single commit, which can be helpful for DevOps teams通过使中间提交成为单个提交来清理中间提交，这对于DevOps团队可能会有所帮助

缺点 (Cons)

• Squashing the feature down to a handful of commits can hide the context将功能压缩到少量提交可以隐藏上下文
• Rebasing public repositories can be dangerous when working as a team团队合作时重新建立公共存储库可能很危险
• It’s more work: Using rebase to keep your feature branch updated always还有更多工作：使用rebase来使功能分支始终保持更新

• Rebasing with remote branches requires you to force push. The biggest problem people face is they force push but haven’t set git push default. This results in updates to all branches having the same name, both locally and remotely, and that is dreadful to deal with.

  要通过远程分支进行基础调整，您需要强行推送。 人们面临的最大问题是他们强制推送，但尚未将git push设置为默认值。 这导致更新具有相同的名称，本地和远程的所有分支，这是可怕的处理。

If you rebase incorrectly and unintentionally rewrite the history, it can lead to serious issues, so make sure you know what you are doing!

如果您错误地根据基准进行了更改，并且无意间重写了历史记录，则可能导致严重的问题，因此请确保您知道自己在做什么！

怎么做 (How to do it)

Rebase the feature branch onto the master branch using the following commands.

使用以下命令将Feature分支重新建立到master分支上。

$ git checkout feature
$ git rebase master

This moves the entire feature branch on top of the master branch. It does this by re-writing the project history by creating brand new commits for each commit in the original (feature) branch.

这会将整个功能分支移到master分支的顶部。 它通过为原始(功能)分支中的每个提交创建全新的提交来重写项目历史记录来实现此目的。

互动基础 (Interactive Rebasing)

This allows altering the commits as they are moved to the new branch. This is more powerful than automated rebase, as it offers complete control over the branch’s commit history. Typically this is used to clean up a messy history before merging a feature branch into master.

这允许在将提交移到新分支时更改提交。 这比自动重新设置功能更强大，因为它可以完全控制分支的提交历史记录。 通常，这用于在将功能分支合并到master之前清理混乱的历史记录。

$ git checkout feature
$ git rebase -i master

This will open the editor by listing all the commits that are about to be moved.

这将通过列出所有将要移动的提交来打开编辑器。

pick 22d6d7c Commit message#1
pick 44e8a9b Commit message#2
pick 79f1d2h Commit message#3

This defines exactly what the branch will look like after the rebase is performed. By re-ordering the entities, you can make the history look like whatever you want. For example, you can use commands like fixup, squash, edit etc, in place of pick.

这确切地定义了执行变基之后分支的外观。 通过重新排序实体，您可以使历史记录看起来像您想要的任何东西。 例如，您可以使用诸如fixup ， squash ， edit等命令来代替pick 。

使用哪一个 (Which one to use)

So what’s best? What do the experts recommend?

那什么是最好的？ 专家推荐什么？

It’s hard to generalize and decide on one or the other, since every team is different. But we have to start somewhere.

由于每个团队都不相同，因此很难一概而论并决定彼此。 但是我们必须从某个地方开始。

Teams need to consider several questions when setting their Git rebase vs. merge policies. Because as it turns out, one workflow strategy is not better than the other. It is dependent on your team.

团队在设置他们的Git rebase与合并策略时需要考虑几个问题。 因为事实证明，一种工作流程策略并不比另一种更好。 这取决于您的团队。

Consider the level of rebasing and Git competence across your organization. Determine the degree to which you value the simplicity of rebasing as compared to the traceability and history of merging.

考虑整个组织内的基础调整和Git能力水平。 确定与可追溯性和合并历史相比，您对重定基础的简单性的重视程度。

Finally, decisions on merging and rebasing should be considered in the context of a clear branching strategy (Refer this article to understand more about branching strategy). A successful branching strategy is designed around the organization of your teams.

最后，应在明确的分支策略的背景下考虑合并和重新定级的决策( 请参阅 本文以了解有关分支策略的更多信息)。 一个成功的分支策略是围绕团队的组织设计的。

我有什么建议？ (What do I recommend?)

As the team grows, it will become hard to manage or trace development changes with an always merge policy. To have a clean and understandable commit history, using Rebase is reasonable and effective.

随着团队的成长，采用始终合并的策略将难以管理或跟踪开发变更。 为了拥有清晰可理解的提交历史，使用Rebase是合理且有效的。

By considering the following circumstances and guidelines, you can get best out of Rebase:

通过考虑以下情况和准则，可以充分利用Rebase：

• You’re developing locally: If you have not shared your work with anyone else. At this point, you should prefer rebasing over merging to keep your history tidy. If you’ve got your personal fork of the repository and that is not shared with other developers, you’re safe to rebase even after you’ve pushed to your branch.

  您正在本地开发：如果您尚未与其他人共享您的工作。 在这一点上，您应该更喜欢重新合并，以保持历史整洁。 如果您拥有存储库的个人分支，并且未与其他开发人员共享，则即使您已推送到分支机构，也可以安全地进行基础调整。

• Your code is ready for review: You created a pull request. Others are reviewing your work and are potentially fetching it into their fork for local review. At this point, you should not rebase your work. You should create ‘rework’ commits and update your feature branch. This helps with traceability in the pull request and prevents the accidental history breakage.

  您的代码已准备就绪，可以进行检查：您创建了请求请求。 其他人正在审查您的工作，并有可能将其拿到他们的叉子中进行本地审查。 在这一点上，您不应该重新建立工作基础。 您应该创建“返工”提交并更新功能分支。 这有助于拉取请求中的可追溯性，并防止意外的历史记录损坏。

• The review is done and ready to be integrated into the target branch. Congratulations! You’re about to delete your feature branch. Given that other developers won’t be fetch-merging in these changes from this point on, this is your chance to sanitize your history. At this point, you can rewrite history and fold the original commits and those pesky ‘pr rework’ and ‘merge’ commits into a small set of focused commits. Creating an explicit merge for these commits is optional, but has value. It records when the feature graduated to master.

  审查已完成，可以集成到目标分支中。 恭喜你！ 您将要删除功能分支。 从现在开始，考虑到其他开发人员将不会进行这些更改的合并，这是您清理历史的机会。 此时，您可以重写历史记录并将原始提交以及那些烦人的“ pr rework”和“ merge”提交折叠为一小组集中的提交。 为这些提交创建显式合并是可选的，但很有用。 它记录功能何时毕业掌握。

结论 (Conclusion)

I hope this explanation has given some insights on Git merge and Git rebase. Merge vs rebase strategy is always debatable. But perhaps this article will help dispel your doubts and allow you to adopt an approach that works for your team.

我希望这种解释能对Git合并和Git变基有所启发。 合并与变基策略始终值得商bat。 但是也许本文将有助于消除您的疑虑，并允许您采用一种适合您的团队的方法。

I’m looking forward to writing on Git workflows and concepts of Git. Do comment on the topics that you want me to write about next. Cheers!

我期待着撰写有关Git工作流程和Git概念的文章。 对您要我接下来写的主题发表评论。 干杯!

code = coffee + developer

code = co ffee + de veloper

coding school for software developers

软件开发人员编码学校

翻译自: https://www.freecodecamp.org/news/an-introduction-to-git-merge-and-rebase-what-they-are-and-how-to-use-them-131b863785f/