使用Github在Git中提交多个pull请求（常规流）

我无论如何都不是git专家，所以我想确保以下流程良好：

找到我想参与的回购协议（原始回购）

在github上分叉原始回购协议（我的叉子）

克隆我的fork到我的机器，在我正在进行的任何项目之外（隔离克隆）

将我的fork作为我想在其中使用的项目的子模块（子模块克隆）

在隔离克隆上创建一个功能分支，并添加一些内容

创建另一个功能分支和其他不相关的东西

将原始repo作为远程添加到我的隔离克隆中

重新设定原始回购的基础

将两个功能分支推拉到我的独立克隆的主节点中

从我的项目中的子模块克隆中提取

从隔离克隆中的每个功能分支向原始repo提交拉取请求

请求被接受

重新设置my fork的主分支的基础，以反映带有我的更改的新主分支

有什么错误吗

那么，我应该如何处理本地机器上的功能分支呢？也许可以把它们重新放给我当地的主人？删除它们（这很糟糕吗？）

如果他们不接受我的请求，我仍然希望将它们合并到我的本地主机中。那会把事情搞砸吗

我试图找出一个流程，允许我提交基于功能的请求，但也可以在项目中使用我的更改，而不管它们是否被接受，以及在它们接受/拒绝后直接使用我的本地副本

有很多要读的，但是谢谢你的帮助

---

编辑：一天后找到了这篇相关文章。没有回答我问题的复杂性，但仍然很有用：

子模块部分使事情变得有点复杂，但除此之外：

• 9:拉？您可以将两个功能分支推到分支（“孤立克隆”），而不是拉它们。这将在远程回购上保存这些提交。
  实际上，对于pull请求，您应该推送一个分支，其中包含您想要提议的所有提交。见下一点
• 11：提交拉取请求：拉取请求背后的想法是为原始项目提出快进合并。
  因此，当您需要重新确定要包含在分支顶部的拉取请求中的提交（例如

  master

  ）的基础时，原始回购必须随您的提交而更新。为此，建议：
  • 首先从原始回购中提取（以确保主回购是最新的）
  • 在

    master

    上重新设置功能分支的基础（这里再次以

    master

    为例）作为一个新分支（并测试最初在各自分支中开发的两个新功能是否协同工作）
  • 把那根新树枝推到你的叉子上
  • 将新分支的提交提议为

    master

如前所述，如果您是唯一一个处理该特性分支的人，则可以使用重基（然后可以使用

push--force

）

如果你想对一个项目作出贡献，你不应该直接修改你将要参与的分支提交的历史记录：如果你想向原始回购的

master

发出请求，你不应该向你的分支的

master

推送任何东西（从原始回购的pull发出的提交除外）

---

您应该始终在专用分支中工作。

我认为这是一个正确的说法：当在master上重新设置基址时，您对功能分支的提交将被压缩为一次提交（因为

rebase

在一次提交中生成并应用补丁到

master

），然后，当原始的repo

pull

s时，它们将只有一个提交，包含该特性的所有更改。这准确吗？@Justin：不太准确，因为默认情况下，重基不会挤压（当然，您可以使用它挤压提交：）。目标不一定要有一个由一个提交组成的拉请求（即使通常是这样），而是一个由提交的清晰历史组成的拉请求，允许在调试时停止

git对分

，我只想指出，只有当某个功能分支只存在于一个您专用的存储库（即独立克隆或子模块克隆）中时，才应将该功能分支重定为主功能分支。否则，应该将master合并到您的特性分支中。这种合并非常重要，因为它可以避免您（希望其他人）多次需要解决相同的合并冲突。@koffie我同意。我已将您的评论包含在答案中，以提高可视性。