2

github でホストされているサードパーティのオープン ソース プロジェクトに依存するアプリケーションがあります (「https://github.com/3rd-party-org/3rd-party-lib」と呼びましょう。このプロジェクトには「マスター」ブランチがあります)。および複数のバージョン固有のブランチ (「xy」、「xz」など)。

(a) サード パーティのプロジェクトのブランチを最新の状態に保ち、(b) それらの修正を含む私の修正を含む開発マシンのローカル ブランチを維持しながら、オープン ソース プロジェクトに修正を時折提出できるようにしたいと考えています。私がまだサードパーティのプロジェクトに提出していないもの、および私が提出したものの、まだ受け入れられてマージされていないもの (そして、おそらく決してそうではないかもしれませんが、それでも私は自分で使用するためにそれらの変更が必要です)。

私は git にかなり慣れていないので、ここで右足で降りたいと思います。

これが私が考えていることです。これが理にかなっているかどうか、またはより好ましい代替手段があるかどうかについてアドバイスしてください。

初期設定として:

  • 「https://github.com/3rd-party-org/3rd-party-lib」をローカルの開発環境に複製します
  • 私のローカルリポジトリで、サードパーティが定義した各ブランチからブランチを作成します。たとえば、「master」からブランチ「my-master」、「xy」から「my-xy」などです。
  • github のサード パーティ リポジトリをフォークします (例: "https://github.com/me/3rd-party-lib")。修正をプッシュする場所があり、そこからプル リクエストをサード パーティに送信できます。 libメンテナ。

サードパーティ プロジェクトの修正に取り組みたい場合、(ローカルの開発環境で) 次のようにします。

  • origin/master から取得して、「master」が最新であることを確認します
  • 「マスター」を「マイマスター」にマージ
  • "master" からトピック ブランチを作成します (例: "issue-123")。
  • 準備ができたら、トピック ブランチを github のフォークされたレポにプッシュし、サードパーティ プロジェクトにプル リクエストを送信します。
  • ローカル環境に戻り、トピック ブランチを「my-master」にマージします。これにより、依存プロジェクトを「my-master」に対してビルドするときに、すべての修正が表示されます。
  • 該当する場合は、「my-master」の代わりにライブラリの特定のバージョンに対してビルドできるように、「my-master」からチェリーピックして「my-xy」または「my-xz」ブランチに修正をバックポートします。最先端で生きたくないのなら。
4

1 に答える 1

0

これは、サードパーティのライブラリがプルまたはパッチを受け入れる方法によって異なります。ダイレクト フォークからのプル リクエストを受け入れる人もいれば、ブランチの使用を要求する人もいます。さらに、プル リクエストを受け入れず、パッチを別のソースから入手するよう求める人もいます。

パッチをサードパーティに戻す詳細は別として、最大限の柔軟性を得るために正しい道を歩んでいるようです。

于 2012-05-14T18:57:54.330 に答える