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

GIT 分支概述

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

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

合并

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

什么是合并提交？

在 GIT 中，每个提交都有一个父提交，除了合并提交，它们有两个或更多父提交。 命令 `git merge master` 创建一个具有两个父提交的合并提交：您的分支的最后一个提交和 master 的最后一个提交。 因此，通过检出此提交，您将同时拥有 master 和您的分支上的更改。 在合并期间，如果两条分支上修改了相同的行，则可能会出现冲突。 在这种情况下，必须手动解决这些冲突。

在合并之前，始终确保您的分支与远程分支保持同步。

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

缺点是大量的合并提交可能会使分支历史难以阅读。

变基 (Rebase)

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

为了能够做到这一点，需要修改分支上的所有提交，因为这样它们将包含在 master 上完成的更改。 由于您正在更改提交，因此它们的哈希 ID 也将更改。 因此，从技术上讲，它们将是新的提交。 这也意味着在 git log 中可能会出现同一提交的多个实例（rebase 和非 rebase）。 你真的必须注意！

此外，git rebase 是逐个提交地完成的，因此相同的冲突可能会一次又一次地出现。

这种方法的优点是您的历史记录将保持一条直线，另一方面，以后无法判断是否发生了 git rebase。

如果多个开发人员在同一分支上工作，您应该特别注意 rebase。

Cherry-Pick

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

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

Merge、Rebase 和 Cherry-Pick 总结

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

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

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