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