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

【问题标题】：Continue working on a Git branch after making a pull request发出拉取请求后继续在 Git 分支上工作
【发布时间】：2013-08-04 00:27:17
【问题描述】：

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

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

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

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

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

这都是在使用 Github，尽管我认为答案一般适用于 Git。

【问题讨论】：

【解决方案1】：

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

feature2 然后可以在以后合并（有些人会争辩在 feature1 被合并到上游的提交上重新设置 feature2，但个人我不喜欢变基）。

【讨论】：

那么如果feature 1被合并到master中，如果我稍后将feature 2（基于feature 1）合并到master中就不会有冲突问题了？
@IsaacDontjeLindell feature2 基于 feature1 的事实不会引入额外的冲突，不会。当然可能存在冲突，但它们与它基于 feature1 的事实无关。此外，如果 feature1 被拒绝，合并 feature2 会再次将其拉入，除非你先 rebase feature2。
@IsaacDontjeLindell 提示：您可以使用实验后删除的本地克隆尝试所有这些。
@mnagel 如果功能 1 被拒绝并需要一些细微的更改怎么办？更改已添加到功能 1。然后我猜这些提交需要在功能 2 完成并准备好合并到 master 之前合并到功能 2 中？并且功能 1 总是需要在功能 2 之前合并到 master 中？
这就是我一直在做的事情（使用 Git TFS）。我从这种方法中注意到的唯一缺点是拉取请求是相对于主控的，因此Feature2 拉取请求差异也会显示来自Feature1 的更改，这会使拉取请求膨胀并隐藏 Feature1 和 Feature2 之间的区别变化。