GitHub Rebase & Merge 创建新的提交哈希

Luk*_*uke 12 git github

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

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

8b08096 - mod4
97eff67 - mod3
b64891f - mod2
fa6e804 - mod1
956e388 - initial
Run Code Online (Sandbox Code Playgroud)

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

956e388 - initial
Run Code Online (Sandbox Code Playgroud)

mod1我现在想将, mod2& mod3from 的提交“推广”masterstaging分支。因此,从staging我创建一个新的临时分支并合并提交开始,直到mod3

git checkout staging
git checkout -b promote
git merge 97eff67
Run Code Online (Sandbox Code Playgroud)

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

git log --pretty=oneline

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

git push origin promote
Run Code Online (Sandbox Code Playgroud)

我现在可以为团队创建 PR 来审核更改。

然而,当谈到将其合并到staging分支时,GitHub 给了我 3 个选择;合并、挤压和合并以及变基和合并。我不想进行合并,因为这会给我一个合并提交。我不想进行 Squash & Merge,因为这会将我的所有提交压缩为一个提交,所以我只剩下 Rebase & Merge。

当我进行变基和合并时,所有更改都会应用于分支staging。然而,所有提交现在都被赋予了新的哈希值(当然“初始”提交除外):

2d7177a - mod3
2831f46 - mod2
a8a2e15 - mod1
956e388 - initial
Run Code Online (Sandbox Code Playgroud)

如何将promote分支中的提交合并到staging分支中,同时保持提交哈希完好无损?

tor*_*rek 11

这是完全正常的:1 个rebase副本提交到新的和(据说)改进的提交,这意味着它们将具有不同的哈希 ID。

\n
\n

如何将提升分支中的提交合并到暂存分支中,同时保持提交哈希完好无损?

\n
\n

不使用REBASE AND MERGE

\n

GitHub 没有提供一个按钮来执行我希望他们允许的操作。这意味着如果您希望合并 GitHub上的分支,则必须使用该MERGE按钮。

\n

要在没有“合并气泡”(即无合并提交)的情况下作为快进进行合并,您必须在自己的计算机上执行快进,然后用于git push将更新的提交哈希 ID 发送到 GitHub。那是:

\n
git fetch\n
Run Code Online (Sandbox Code Playgroud)\n

(这样你就可以在笔记本电脑上或任何\xe2\x80\x94上拥有所有内容,这一步通常是不必要的,但不会有什么坏处),然后:

\n
git checkout staging\ngit merge --ff-only origin/staging   # if needed\n\ngit merge --ff-only origin/promote   # whatever fast forward you want here\ngit push origin staging\n
Run Code Online (Sandbox Code Playgroud)\n

staging仅当您自己的步骤落后staging时才需要结账并快进。这些命令实现了快进而不是合并操作。origin/staginggit fetchgit merge --ff-only

\n
\n

1无论如何,对于 GitHub 来说是正常的。有些系统允许在这里进行快进合并操作,而这种情况不会发生。GitHub 不是其中之一。 REBASE AND MERGE进行强制变基,使其“正常”。

\n

  • 至于“[Github]复制提交到新的和(据称)改进的提交”,我想知道为什么他们认为提交得到了改进。我和支持人员聊天,但他们没有任何理由。 (2认同)
  • @Garrett:他们有不同的提交者字段(由执行变基的人配置)和时间戳。就我而言,并没有太大的进步。它们“可能”也有不同的父哈希 ID,在这种情况下,复制是强制的,但它们也可能没有,在这种情况下,我只是觉得很烦人。 (2认同)
  • @torek我会说这不是“完全正常”,因为例如 gitlab 的做法不同,并且允许在进行快进合并时不更改任何提交哈希。在我看来,这个 github 功能已经很糟糕了。“rebase and merge”在后台执行相当于“git rebase --force”的操作,而不是执行简单的“git rebase”,这对于快进合并来说是一个 NO-OP。 (2认同)
  • @Étienne:我添加了脚注。这对于 GitHub 来说很正常,因为 GitHub 很烦人。:-) 请注意,GitLab 在这里的操作就是我所说的“GitHub 不提供可以执行我希望他们允许的操作的按钮”。 (2认同)