在进行具有雇主特定更改的开源项目时，最好的Git工作流程是什么？

在我目前的雇主那里，我们正在使用托管在Github上的开源项目作为应用程序的一部分。我一直在从事这个项目，既添加了我们需要的一些功能，又将其与我们的构建系统集成在一起。我的经理和我都同意，我们将在合理范围内尽可能多地将我们的工作提交给开源项目。我的问题是，最好的工作流程/技术是什么，以这样一种方式来维护我的Git提交，以便我可以轻松地分离出有意义的东西，并重新添加到开源项目中-漏洞修复和足够通用的新功能-特定于我们项目的内容，例如构建位置和应用程序常量。

到目前为止，我一直在维护一个私有的Git分支，在其中我以适当的粒度提交所有更改。然后cherry-pick，我用于将可开源的提交添加到master分支，并将其提交回Github。

似乎我应该使用merge来执行此操作，这样我就不会继续创建具有相同内容的单独提交，但是我不确定如何在排除公司特定的提交并保持合理的工作流程的同时执行此操作。

例如，我想我可以在私有分支上对master和公司特定的东西提交可开源的东西，然后根据需要将master合并到该分支中，而使master分支指向合并之前的提交，这样我就可以再次向其提交可开源的内容，然后再次合并。这个工作流程似乎很尴尬，因为我要做的每件事都要事先确定它属于哪个分支，将其处理为看起来像完成的部分，然后提交并合并再进行测试。我真正喜欢Git的一件事是，要做任何使应用程序正常工作的事情，然后决定以后如何以及在何处提交更改，这是多么容易。据我所知，如果您目前在分支机构中并且已经完成了一些工作，

我正在做一个合理的工作流程以获得长期贡献吗？有人可以推荐一个可能更好的不同工作流程吗？为什么会更好？

这是一种可能对您有用的策略：

创建2个私人git仓库，一个仓库用于公司工作，另一个仓库作为一般仓库（我想提交）。

为了使该系统正常工作，您需要执行以下操作（我认为这是最重要的策略）：定义什么是“一般”的，并可由社区中的其他所有人使用

通过定义，您可以分离出将要提交的内容和不需要提交的内容。

您为社区编写的代码应该具有一般性的形式，这是有道理的，因为过于具体的一段代码不会使任何人受益（甚至可能不会传递给master分支）。

既然您知道要对社区做出什么承诺，就可以在专用于该社区的回购中完成大多数“回馈”工作。然后，您只需将该仓库分叉到您的基于工作的仓库中，并在此基础上执行任何特定于工作的工作。

我怀疑您会在“回馈”回购中花费更多时间，因此请记住为将来使用该项目的人员提供有价值的评论等（甚至是文档）。

我也相信git可以做的比您想像的要多得多。我在Vimeo上观看了此视频：http : //vimeo.com/46010208，她出色地解释了git可以做的许多古怪的事情。

我的策略不是唯一的策略，但是绝对可以作为您考虑特别适合您的1的起点。

根据开源代码库的性质以及您需要对其进行更改而实现的目标，分离关注点可能会带来很多麻烦。在项目的分支中，仅添加您打算贡献回原始内容的内容。添加挂钩或扩展点，以允许您完成公司工作，而这些工作不会共享。

这样，您将不必担心划分或预先确定共享的内容和不共享的内容。因为您为原始项目增加了灵活性，所以以后您始终可以选择共享公司工作的某些部分。