git: 合并pull request后如何获取新的develop分支?

git: How to get the new develop branch after merging a pull request?

我做了一个 git 的 repo 克隆,然后 git checkout develop 然后我创建了一个功能分支,做了一些更改,提交并推回 github。然后,在github里面,我接着做了一个pull request把它pull到develop,merge到develop。如果我进入 github 网站和 select 开发分支,我会在源代码中看到我的更改。

但是我找不到方法让新的开发分支回到我的mac。

如果我执行 git 提取,我不会收到任何错误。然后我做 git checkout develop,但我只看到我的旧代码。显然我没有对我的 machine 进行任何更改,它们只是通过 pull request/merge.

在 github 中发生的

如何获得新的开发分支?

我在 "git merge develop" 进行了猜测,虽然这看起来是错误的,但没有要合并的东西,我只想从获取的更新中检出开发。 "git merge develop" 只是说 "already up to date",虽然它不是。

我也试过 git 拉。这给出了一个错误信息,并建议:

git 分支 --set-upstream-to=origin/ develop

这似乎很激烈,我不知道这会产生什么副作用。

显然,我可以求助于删除整个项目,然后从头开始克隆,但我想有更简单的方法吗?

仅供参考,在服务器上,我尝试执行 git 克隆,然后 git 签出开发,然后我看到了新代码。

此外,在我的 mac 上,如果我这样做 "git status",它会说:

在分支开发中, 没有什么可提交的,工作树干净

另请注意,我不是在使用 fork,而是直接在主要(且仅)github 存储库上进行分支。

你应该做的:

git checkout develop
git pull

那就是fetched+merge。

以你目前的情况,你还可以做到:

git checkout develop
git fetch
git merge origin/develop

您可以删除您自己的develop,然后再次git checkout develop,或者——至少有时/通常——这样做:

$ git fetch              # if needed
$ git checkout develop
$ git merge

不过,事实上,您甚至 不需要 自己的 develop

一旦你明白在 Git 中,分支 names 只是指针,一切就都清楚了。 Git 中真正重要的是 提交 。每个名称——无论是像 developmaster 这样的分支名称,还是像 origin/develop 这样的 remote-tracking 名称——都只是指向一个提交。提交代表实质;这些名称正是 Git 查找 提交的方式。

让我们看看您开始时有什么,但让我们从绘制提交开始。每个提交都有一些丑陋的大哈希 ID 作为其真实名称,但这些对于人类来说太笨重了,所以让我们使用单个大写字母来表示提交。我们还要注意,每个提交都会记录其 parent 提交的哈希 ID。当某物持有提交的哈希 ID 时,我们说这个东西 指向 提交。因此,如果提交 A 先出现,然后 B 记住 A 的哈希 ID,B 指向 A:

A <--B <--C

等等。因为新的提交 link 到旧的(不是旧的提交到新的),并且因为一旦提交完成,提交中的任何内容都不能 改变 ,所以这些箭头总是指向后方, 所以为了方便我们可以把它们画成线。

因为散列 ID 看起来是随机的,Git——而你——需要某种名称来保存 last 提交的散列 ID:

A--B--C   <-- origin/develop

多个名称可以包含相同的哈希 ID,如果您现在 运行 git checkout develop 就是这种情况,它会注意到您 没有 一个 develop,但是你确实有一个 origin/develop,所以它现在 创建 你的 develop

A--B--C   <-- develop (HEAD), origin/develop

(Git 将单词 HEAD 附加到一个分支以记住哪个分支是您的活动分支,当前分支。将它包含在您的绘图中是个好主意。)

如果您现在创建一个功能分支 feature,Git 也会使其指向提交 C

A--B--C   <-- develop, feature (HEAD), origin/develop

当您进行 new 提交时,Git 创建指向当前提交的新提交——提交 C,通过 [=37= 找到]—然后更新通过 HEAD 找到的当前名称,使其指向指向 C:

new 提交
A--B--C   <-- develop, origin/develop
       \
        D   <-- feature (HEAD)

你现在 git push feature 到 GitHub,它在另一个 Git 上创建一个名为 feature 的分支,你的 Git 调用 origin,所以现在 有:

A--B--C   <-- develop, origin/develop
       \
        D   <-- feature (HEAD), origin/feature

请注意,您的 Git 只是通过这些 origin/ 名称记住 他们的 Git 的分支在哪里。

有人现在将您的提交合并到原点的 develop 中。结果是——嗯,可能,取决于这个"someone"如何在GitHub上完成操作——画成这样:

A--B--C   <-- develop
       \
        D   <-- feature (HEAD), origin/develop, origin/feature

如果您现在 git checkout developHEAD 附加到 develop,您将得到:

A--B--C   <-- develop (HEAD)
       \
        D   <-- feature, origin/develop, origin/feature

如果您现在要求您的 Git 将您的 developorigin/develop 合并,您的 Git 会注意到它可以作为快进操作执行此操作 —不是合并,真的——它产生:

A--B--C
       \
        D   <-- develop (HEAD), feature, origin/develop, origin/feature

但请注意,如果您只是 删除 名称 develop,而不附加 HEAD,您会得到:

A--B--C
       \
        D   <-- feature (HEAD), origin/develop, origin/feature

从某种意义上说,这同样好。如果你想现在创建 feature2,你现在可以创建那个分支名称,然后删除 featuregit push --delete origin feature,给出:

A--B--C
       \
        D   <-- feature2 (HEAD), origin/develop

请注意 提交 如何始终保持不受侵犯。提交是 Git 存在的原因。分支和远程跟踪名称 一直在变化 。分支名称尤其会因您进行新提交的行为而发生变化。当你 git push 成功时,你的远程跟踪名称会改变——你的 Git 知道他们的 Git 已经接受了新的提交到他们的分支名称中——当你 git fetch 因为你的Git 刚刚获得了他们所有的最新提交并且知道他们的分支名称现在在哪里。这些是移动的部分。提交不会移动:它们只会随着时间的推移而累积。