gitcherry-pick 和 github 拉取请求不同步

Question

在我们的例子中，我们不想在 GitHub 上提出 PR。相反，我们更喜欢使用cherry-pick将文件从cherry-pick-test分支合并到主分支并保持代码最新。

为了实现这一目标，我们执行了以下步骤。可以按照以下步骤重现该问题：

    git clone repo-url
    git checkout -b cherry-pick-test
    echo "commit-1" > cherry_test.txt
    git add .\cherry_test.txt
    git commit -m "commit-1"
    git push origin cherry-pick-test
    git log --graph --oneline --all # I performed this command to get commit hash, you can use convenient command to gather same info 
    git checkout main
    git cherry-pick aab828a894dd13c05bc16ed799a7842c6a8c4d6b
    git push origin main

执行上述命令后，主分支已更新，这意味着cherry_test.txt已合并/添加到主分支。

有时，我们需要将 PR 从cherry-pick-test 提升到main。在此期间，我预计“commit-1”（提交哈希 aab828a894dd13c05bc16ed799a7842c6a8c4d6b）中的更改不应再次显示以进行合并，因为它们已经使用cherry-pick 推送到了 main。

我的期望是，当我提出 PR 时，它不应该显示 PR 中之前精心挑选/合并的文件。我们能做到这一点吗？或者系统就是这样设计的吗？我感谢你的帮助。

下面附上GitHub中提出的PR截图。

Answer 1

正如 @j6t 在评论中所说，合并分支时，Git 会根据提交而不是更改进行推理。在这种情况下，Git 会查找两个合并分支分歧的提交（合并基础）。选择提交后，Git 会将两个分支引入的所有更改添加到合并基础上，然后完成合并，除非存在任何冲突。在最后一个场景中，Git 将冲突解决和合并完成的负担留给了用户。

相反，当挑选一个提交时，Git 会创建一个全新的提交（具有不同的 SHA1），它引入了与挑选的修订版相同的更改。

因此，当您将

cherry-pick-test

合并到

main

时，Git 首先选择

cherry-pick-test

的 head 的父提交作为合并基础，然后在其上添加

cherry-pick-test

和

 引入的更改main

。然而，由于两个分支只是从其合并基础提前一个提交，并且由于两个提交都引入了完全相同的更改；在 GitHub 上检查您的 PR 时，它会将来自两个不同提交的两个更改列为单个更改。

我的期望是，当我提出 PR 时，它不应该在 PR 中显示之前精心挑选/合并的文件。我们能做到这一点吗？或者系统就是这样设计的吗？

所以，回答你的问题：

不，如果不显示来自看起来相同的不同提交的更改，则无法实现 PR。如上所述，合并分支时，Git 根据提交而不是原始内容进行推理。