Question

我正在解决TeamCity构建GitHub拉取请求的问题，如this blog post中所述，我正在尝试在本地复制结帐行为。

以下是我正在遵循的步骤序列：

// in /projects/semver_demo/master 
git checkout master
echo "Hello World!" > master.txt
git add .
git commit -m "edited master.txt"
git push
git branch foo
echo "Hello World!" > foo.txt
git add foo.txt
git push

现在我转到GitHub，从分支foo打开拉取请求＃123。然后在一个单独的回购中，我已经在另一个文件夹中检出，我正在查看我认为当前的合并头对于拉取请求＃123：

// in /projects/semver_demo/merged
git fetch origin refs/pull/123/merge:pr123
git checkout pr123

好的，到目前为止，这么好 - 我在一个包含我的功能的分支上。现在，我将回到我的工作文件夹，模拟对master进行一些更改，正如我所理解的那样 - 应该在我再次获取合并头时出现。

// in /projects/semver_demo/master
git checkout master
echo "Hello again!" >> master.txt
git add master.txt
git commit -m "Added another line to master.txt"
git push

现在，切换回我的feature_branch文件夹并删除并重新获取合并头：

// in /projects/semver_demo/merged
git checkout master
git branch -D pr123
git fetch origin refs/pull/123/merge:pr123
git checkout pr123

当我这样做时，我希望看到新的“你好再见！” merged/master.txt中的消息，但我不是 - 我看到创建分支时存在的master.txt版本相同。

我的理解是合并头会给你相当于将当前主（或上游分支）合并到功能分支的当前HEAD中 - 但这不是我所看到的。我是否错过了一些微妙的步骤来告诉Git“重新合并”合并头？或者我完全误解了合并头的目的？

编辑：经过多一点调查后，将更改推送到foo会导致合并负责人反映master的最新更改...但是将更改推送到{ {1}}没有。我现在想知道这种行为是否符合设计要求？

Answer 1

我已经通过GitHub支持验证合并头仅在更改被推送到分支头时更新;它们不会更新以反映对基本分支的更改 - 因此，如果您基于拉取请求合并头构建预发布包，请始终在构建包之前立即将更改推送到PR分支。如果你正在使用VCS触发器来启动你的包构建，那么无论如何都会发生这种情况，所以我认为这是在现实生活中不会经常发生的那些模糊的边缘情况之一。

有关于此的详细说明，以及它如何影响我们正在使用的GitHubFlow工作流程，http://www.dylanbeattie.net/2017/01/semantic-versioning-with-powershell_26.html

为什么主人的更改没有出现在我的GitHub合并头？

1 个答案: