我们已经在GitHub上派生了一个OSS项目，并且正在为其添加一些自定义扩展。我们希望发送一些我们对原始项目所做的更改（错误修复等），但其他更改是原始项目维护人员目前不感兴趣的功能扩展。我试图找出管理这种情况的最佳工作流程。用于维护项目扩展叉的Git工作流？
我希望我们的主分支包含（原始项目提交）+（我们对贡献的bug修复）+（我们的自定义扩展）的总和。我想我们会需要一个按功能分支的模型，以便我们可以将错误修复与定制扩展分开。我们可以从我们的主分支开始自定义的扩展分支，但是我想我们也想维护一个本地的“origin”分支或者跟踪原始项目的东西，这样我们就可以从那里开始那些没有被我们污染的bugfix分支定制的东西。或者其他的东西。
任何人都可以建议构建这个工作流程的最佳方式，使所有的各种提交去他们应该去的地方，没有去他们不应该去的地方？
这听起来像你已经回答了你自己的问题。创建一个名为“vanilla”的分支或跟踪上游主分支的分支，并拥有一个包含您的自定义扩展的“主”分支。为你做的每件事创建分支。对于错误修正，从“香草”开始。为了你自己的东西，从主人开始。每过一段时间，香草就会变成主人。为了将错误修正到你的自定义扩展分支中，你可以直接将他们的分支合并到master中，或者等待上游接受你的错误修正请求，然后从vanilla到master的下一个合并将包含错误修正。这似乎是一个非常正常的工作流程。
你想设置什么是长期叉，要做到这一点，你已经想出了解决办法是建立与原来的“香草”项目链接的特殊分支，有一个主分支，你保持您的自定义工作副本。
您必须记住的唯一事情（从我的角度来看）是，当您想同步更改时，您不应该合并两个分支，但在这种情况下（分支机构分支）是方便的Git Cherry-Pick命令，它允许您从一个分支采取单一提交并将其应用到另一个，这可能在维护分支的情况下特别有用，因为您可以轻松地将单个提交从一个分支交换到另一分支。 。