雇用主固有の変更を伴うオープンソースプロジェクトで作業するための最高のGitワークフローは何ですか？

私の現在の雇用者では、Githubでホストされているオープンソースプロジェクトをアプリケーションのコンポーネントとして使用しています。私はこのプロジェクトに取り組んでおり、必要な機能を追加したり、ビルドシステムと統合したりしています。私のマネージャーと私は、このコンポーネントに関する作業を、オープンソースプロジェクトに合理的な範囲で提出することに同意します。私の質問は、オープンソースプロジェクトに追加する意味のあるもの-バグ修正と十分に一般的な新機能-を簡単に分離できるように、Gitコミットを維持するための最良のワークフロー/テクニックについてです。ビルドの場所やアプリケーションの定数など、プロジェクトに固有のものから。

これまで行ってきたことは、適切な粒度ですべての変更をコミットするプライベートGitブランチを維持することです。次にcherry-pick、オープンソースのコミットをmasterブランチに追加し、Githubに送信します。

私はこれを行うためにマージを使用する必要があるようです。そのため、同じ内容の個別のコミットを作成し続けることはできませんが、会社固有のコミットを除外して合理的なワークフローを維持しながらこれを行う方法はわかりません。

たとえば、マスターでオープンソース可能なものとプライベートブランチで会社固有のものをコミットし、必要に応じてマスターをそのブランチにマージし、マージ前にマスターブランチがコミットを指すようにして、オープンソース可能なものを再度コミットしてから、再度マージします。このワークフローで厄介なように思えるのは、どのブランチに属しているかを行うすべてのことを事前に決定し、完了したと思われるものに取り組んでから、テストしてからコミットしてマージする必要があることです。Gitで私が本当に気に入っていることの1つは、アプリケーションを機能させるために必要なことを何でもすることが簡単で、後で変更をコミットする方法と場所を決めることです。私が知る限り、あなたが現在ブランチにいて、何らかの作業を行っている場合、

私は長期的な貢献のために合理的なワークフローを行っていますか？誰かがより良いかもしれない別のワークフローを推奨できますか？なぜそれが良いですか？

効果的な戦略は次のとおりです。

2つのプライベートgitリポジトリを作成します。1つは会社の作業用で、もう1つは一般的な（コミットしたい）リポジトリです。

このシステムを機能させるには、これを行う必要があります（最も重要な戦略と考えています）。「一般」であり、コミュニティの他の全員が使用できるものを定義します

この定義を使用すると、コミットするものとコミットする必要のないものを区別できます。

コミュニティ向けにコーディングするものは一般的な形式であることが理にかなっています。あまりにも具体的なコードは誰にも役立たないでしょう（そして、マスターブランチにたどり着かないかもしれません）。

コミュニティにコミットする内容がわかったので、専用のリポジトリでほとんどの「ギブバック」作業を行うことができます。次に、そのリポジトリを作業ベースのリポジトリにフォークし、その上で作業固有の作業を行うだけです。

"give-back"リポジトリにもっと多くの時間を費やすことになるのではないかと思うので、将来そのプロジェクトを使用する人々に貴重なコメントなど（おそらくドキュメント）を提供することを忘れないでください。

また、gitはあなたが思っている以上に多くのことができると信じています。私はVimeoでこのビデオを見ました：http : //vimeo.com/46010208、彼女はgitでできる奇抜なことをたくさん説明してくれました。

私の戦略はそこにある唯一のものではありませんが、あなたに特に合った1を考えるための出発点になることは間違いありません。

オープンソースのコードベースの性質と、それを変更して何を達成する必要があるかに応じて、懸念を分離することで多くのマイレージを得ることができます。プロジェクトの分岐点で、オリジナルに貢献するものだけを追加します。フックまたは拡張ポイントを追加して、共有されない会社作業を行えるようにします。

このように、共有するものと共有しないものを分けたり、事前に決定することを心配する必要はありません。元のプロジェクトに柔軟性を追加したため、会社の作業の一部を後から共有することをいつでも選択できます。