GitHub Rebase and Merge 创建新的提交哈希答案

【问题标题】：GitHub Rebase & Merge creates new commit hashesGitHub Rebase and Merge 创建新的提交哈希
【发布时间】：2021-10-22 23:19:48
【问题描述】：

我想通过 PR 审查选择性地将多个提交从一个分支提升到另一个分支。

想象一下，我的 master 分支上有以下提交：

8b08096 - mod4
97eff67 - mod3
b64891f - mod2
fa6e804 - mod1
956e388 - initial

在我的staging 分支上，我只有以下内容：

956e388 - initial

我现在想将mod1、mod2 和mod3 的提交从master“提升”到staging 分支。所以，我从staging 创建一个新的临时分支并合并提交，直到mod3：

git checkout staging
git checkout -b promote
git merge 97eff67

现在执行git log 会向我显示所有提交，包括我的promote 分支上的mod3：

git log --pretty=oneline

97eff67 (HEAD -> promote) mod3
b64891f mod2
fa6e804 mod1
956e388 (origin/staging, staging) initial

git push origin promote

我现在可以创建我的 PR 以供团队审核更改。

但是，在将其合并到 staging 分支时，GitHub 给了我 3 个选项；合并、挤压和合并以及变基和合并。我不想合并，因为这给了我一个合并提交。我不想做 Squash & Merge，因为这会将我所有的提交压缩成一个提交，所以我只剩下 Rebase & Merge。

当我执行 Rebase & Merge 时，所有更改都将应用于 staging 分支。然而，所有的提交现在都被赋予了新的哈希值（当然除了“初始”提交）：

2d7177a - mod3
2831f46 - mod2
a8a2e15 - mod1
956e388 - initial

如何将promote 分支中的提交合并到staging 分支中，同时保持提交哈希不变？

【问题讨论】：

当提交历史允许一个干净的变基时，他们似乎应该给出一个rebase 选项。如果你不是绝对需要 GH PR，你可以手动变基：/
@JScoobyCed 或者他们可以在变基期间尽可能自动复制提交，而不是总是替换它们。如果我的提交上有标签，或者我已经对我的提交进行了 GPG 签名，GitHub 的损坏的 rebase 选项总是会孤立这些标签和签名的提交，因此它们只在我的 PR 分支上而不进入 main。让 GitHub 按原样复制提交的唯一方法（保留提交哈希以保留 GPG 签名和标签）是使用添加冗余提交的合并提交选项。

标签： git github

【解决方案1】：

这很正常：rebase copies 提交到新的和（据说）改进的提交，这意味着它们将具有不同的哈希 ID。

如何在保持提交哈希不变的同时将提升分支中的提交合并到暂存分支中？

不要使用 REBASE AND MERGE。

GitHub 没有提供一个按钮来做我希望他们允许的事情。这意味着如果你想在 GitHub 上合并一个分支，你必须使用 MERGE 按钮。

要在没有“合并气泡”的情况下合并（即，无合并提交）作为快进，您必须在自己的机器上进行快进，然后使用 @ 987654321@ 将更新的提交哈希 ID 发送到 GitHub。那就是：

git fetch

（这样您就可以在笔记本电脑或任何地方拥有所有内容 - 这一步通常是不必要的，但绝不会伤害），然后：

git checkout staging
git merge --ff-only origin/staging   # if needed

git merge --ff-only origin/promote   # whatever fast forward you want here
git push origin staging

只有在git fetch 步骤之后您自己的staging 落后于origin/staging 时，才需要staging 的结帐和快进。 git merge --ff-only 命令实现快进代替合并操作。

【讨论】：