发出拉取请求后继续在 Git 分支上工作

Question

我最近几次发现自己处于这种情况，但我不确定如何最好地处理它。

所以我有一个我贡献的 git 存储库的分支。 我让我的主分支与上游主分支同步。

当我想处理新功能、错误修复等时，我会从我的 master 创建一个分支并做任何工作。 当我完成后，我合并了在此期间对上游 master 所做的任何更改，然后从我的功能/错误修复分支向上游 master 发送拉取请求。

现在，在等待那个拉取请求被接受的同时，我想做一些稍微不同的事情。 但是，新功能工作需要我刚刚发送请求请求的错误修复/新功能。 我需要以此为基础。

我如何以这样的方式分支/合并/处理分支，以便我可以继续工作，同时在第一个拉取请求被 master 接受后仍然能够以干净的方式合并/拉取我的更改中的请求？

这都是使用 Github，虽然我想答案通常适用于 Git。

Answer 1

根据对feature1的最后一次提交创建一个新的分支feature2 。 feature1将不再向前移动，并且可以合并。

然后可以稍后合并feature2 （有些人会争辩说在feature1合并到上游的提交上 rebase feature2 ，但我个人不喜欢 rebase）。

Answer 2

我最近几次遇到这种情况，但我不确定如何最好地处理它。

所以我有一个我正在贡献的git存储库的分支。 我将我的master分支与上游master分支保持同步。

当我想使用新功能，错误修正等时，我会从我的主人那里创建一个分支并进行任何工作。 完成后，我将同时合并对上游主服务器所做的所有更改，然后将来自我的功能/错误修正分支的拉取请求发送到上游主服务器。

现在，当我等待那个拉取请求被接受时，我想做一些稍有不同的事情。 但是，新功能工作需要我刚刚发送请求请求的错误修正/新功能。 我需要在此基础上。

如何以这样一种方式分支/合并/处理分支，以使我可以继续执行工作，同时一旦将第一个拉取请求接受到主服务器中，仍然能够以干净的方式合并/拉出更改中的请求？

尽管我认为答案通常适用于Git，但所有这些都使用Github。

Answer 3

鉴于此工作流程的普遍存在以及沿途的陷阱，我认为缺乏指导。 特别是，OP 提到了 GitHub，但是当您单击此工作流中常见的“使用 rebase 更新”或“使用合并提交更新”按钮时，几乎没有发现会发生什么。

为了更加清楚起见，这里有一种方法应该是说明性的。 首先是设置：

$ git pull # on master branch, will update master branch
$ git switch -c feature1 # create new branch *from master*. Note `switch -c` is the less ambiguous form of `checkout -b` since Git 2.23
$ # work on feature 1
$ git add . && git commit -am "commit1"
$ # more work on feature 1
$ git add . && git commit -am "commit2"
$ git push # pushes "feature1" branch with "commit1" and "commit2", from which you can make a Pull Request to be merged with master.

而现在 OP 的困境 - master 还没有包含feature1 ，那么如何处理依赖它的feature2呢？ 只是从当前分支分支：

$ git switch -c feature2 # create new branch *from feature1*.
$ # work on feature 2
$ git add . && git commit -am "commit3"
$ # more work on feature 2
$ git add . && git commit -am "commit4"

在这一点上，没有什么能阻止你push新分支。 它只会包含commit3和commit4 。 您甚至可以创建一个 Pull Request 以将其合并到 master 中。 但是， 默认情况下GitHub 将阻止您启动合并，因为它检测到分支与主分支“过时”。

所以在这一点上让我们假设远程主机是最新的。 feature1已被合并，可能还添加了其他无关紧要的提交。 我们只需要更新我们自己的分支。 我们可以在当前的feature2分支中舒适地完成所有这些工作：

$ git rebase master # or `git merge master`, pick your poison

现在，就 GitHub 而言，我们的feature2分支是“最新的”，但我们需要推送以便它知道。 但是，如果您喜欢的毒药是rebase类型，请记住您的提交已在新基础上重放，因此就远程而言，它们是不同的提交。 因此，为避免事情变得非常糟糕，此时不要发出git pull ，尽管命令行中的建议是善意的。 相反，做：

$ git push --force-with-lease # safer version of --force. Not necessary if you merged instead of rebased.

瞧，您的 Pull Request 现在将与 master 保持“最新”，合并可以开始了。 另外，我们知道 GitHub 按钮背后的（现在不那么神秘了）魔法：

• “ Update with rebase ”相当于在 PR 分支上发出git rebase master然后是git push --force-with-lease 。
• “ Update with merge commit ”相当于在 PR 分支上发出git merge master然后是git push 。