高级GIT教程——Cherry-Pick vs Rebase vs Merge

目录

GIT分支机构概述

Merge

什么是合并提交？

Rebase

Cherry-Pick

Merge、Rebase和Cherry-Pick的摘要

---

GIT最重要的功能之一就是分支。多个功能的开发可以并行进行，彼此独立。最后，当然需要一个包含多个分支机构功能的版本。本文是有关如何创建此类版本的方法的简要概述。

GIT分支机构概述

在GIT中，每个提交都知道其父级。因此，您的GIT提交列表是一个单向链接列表，代表了提交的顺序。默认情况下，您正在使用一个名为master的分支。分支始终存储为简单的哈希ID，这是分支上最新提交的哈希ID。您可以随时通过git branch branch_name命令基于当前HEAD提交启动新分支。该命令创建一个新分支，指向当前提交。然后您可以通过git checkout branch_name更改到该分支。这会将您的HEAD更改为您的分支。或者，您可以通过键入git checkout -b branch_name一起执行这些步骤。

在分支上，您可以独立于主分支工作。您可以实现新功能，修复错误或进行一些重构。同时，其他人在master分支或其他一些分支上工作。在开始使用功能之前，新功能将添加到master分支中。此时，您必须创建一个版本，其中包含当前主版本的所有内容以及分支中的更改。有三种方法可以做到这一点。让我们看看细节。

Merge

第一种非常经典的方法是git merge。在master分支上（您始终可以通过输入git branch来检查当前分支），键入git merge your_branch。此命令将创建对master分支的新合并提交。

什么是合并提交？

在GIT中，每个提交只有一个父提交，但合并提交有两个甚至更多个父提交。git merge master命令创建一个具有两个父级的合并提交：分支的最后一次提交和master的最后一次提交。这样，通过签出此提交，您将在主数据库和分支机构上都拥有更改。在合并期间，如果在两个分支上修改了相同的行，则可能会出现冲突。在这种情况下，必须手动解决这些冲突。

合并之前，请始终确保您的分支与远程分支是最新的。

git merge最大的优点是提交的历史记录保持清晰和不变。

缺点是大量的合并提交会使分支历史记录不可读。

Rebase

第二个选项是git rebase。Git rebase正在更改分支上第一次提交的父级。因此，git rebase master会将分支的第一次提交的父级更改为master分支上的最新提交。

为此，需要修改分支上的所有提交，因为这样，它们将包含在主服务器上所做的更改。由于您正在更改提交，因此其哈希ID也将更改。因此，从技术上讲，它们将是新的提交。这也意味着同一提交的多个实例（基于和不基于）可以在git日志中出现。您真的要注意！

此外，git rebase是通过commit提交来完成的，因此相同的冲突会一次又一次地出现。

此方法的优点是您的历史记录将保持一条直线，另一方面，以后将无法确定git rebase发生了。

如果多个开发人员在同一个分支上工作，则应特别注意重新编制基准(rebasing)。

Cherry-Pick

如果您只想将一个（或一些）提交从不同分支移到当前分支，那么Git cherry-pick是最好的命令。

例如，您在其中一个分支上有一个错误修复提交，并且您不想将整个分支合并到主分支，而只合并了一个正在修复该错误的提交。您应该检出master分支并输入git cherry-pick commit_id，其中commit_id是bugfix分支的哈希ID。此命令将在master分支上创建一个新的提交（具有新的提交ID），其更改与cherry-picked的提交相同。cherry-picked的提交将保持不变。

Merge、Rebase和Cherry-Pick的摘要

总结一下主题：git merge不会更改任何现有的提交，它只是创建一个新的合并提交，该提交具有两个或多个父级。

Git rebase更改了一个提交的父级（通常是分支的根，或作为参数给出的提交）。换句话说，它正在重写分支（或提交）的历史记录。提交将获得新的哈希ID。

Git cherry-pick使用新的提交ID在当前分支上重新应用一个专用主​​题。cherry-picked的提交保持不变。