在上次提交 feature1 的基础上创建一个新分支 feature2。feature1 将不再向前移动，可以合并。

• feature2* 可以稍后被合并（有些人会争论在 feature1 被合并到上游的提交上重新建立 feature2 的基础，但我个人不喜欢重新建立）。

考虑到这个工作流程的流行和过程沿着的陷阱，我认为缺乏指导。特别是，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。你甚至可以创建一个合并请求来将它合并到master中。然而，默认情况下，GitHub会阻止你启动合并，因为它检测到分支与master“过时”。
现在我们假设远程主机是最新的，feature1已经被合并，也许还有其他无关紧要的提交被添加，我们只需要更新我们自己的分支，我们可以在当前的feature2分支中轻松地完成所有这些工作：

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

现在我们的feature2分支对GitHub来说是“最新的”，但是我们需要推送它才能知道。但是如果你喜欢的毒药是rebase类型的，记住你的提交已经在新的基础上被重放了，所以对于远程控制器来说，它们是不同的提交。不要在此时发出git pull，尽管命令行给出了善意的建议。

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

瞧，你的Pull Request现在已经是master的“最新”请求了，合并可以开始了。另外，我们知道了GitHub按钮背后的魔力（现在不那么神秘了）：

• “使用变基更新”等同于位于PR分支上并发出git rebase master，然后发出git push --force-with-lease。
• “使用合并提交更新”等效于位于PR分支上，并发出git merge master，然后发出git push。