web-dev-qa-db-ja.com

アップストリームがプルしない機能ブランチを持つフォークされたgitリポジトリを維持する方法は？

これがGithubの典型的なワークフローです...

  1. いくつかのプロジェクトのように-> fork it ->git clone https://github.com/you/someproject。

  2. プロジェクトを開きます。あなたが見るものに似ていますが、いくつか変更を加えます。

  3. feature-branch（git checkout -b some-feature）でのみ機能するように注意して、feature-branchをGithubフォークにプッシュした後、upstreamメンテナでプルリクエストを行うことにしました。

  4. メンテナは、何らかの理由でプルを拒否します。

例.. 上記のシナリオに一致する、私が送信した失敗したプルリクエストです ..

今typical、メンテナHADがマージされた場合プル...ワークフローは簡単です...私のローカルマシンでは、そのときに行っていたfeature-branchのローカル変更をコミットします... git fetch --all、git checkout master、git pull upstream --ff-only。次に、必要に応じて、その上で変更を再生します...

だが...

私のフォークへの変更を無理なく続けたいと決心した場合はどうなりますか...それでも、発生する変更を追跡+マージできるようにしたいですかupstream？通常、私は機能ブランチを削除して、先に進みます。上流でマージできるmasterブランチを維持しながら、upstreamのHEADから「永続的に分離」しながらフォークの機能を維持するにはどうすればよいですか。

open-sourcegitworkflowsforkingetiquette
8
alex gray

シナリオの使用に関係なく、これを行う方法を次に示します。

  • マスターは、上流のマスターが持っているバージョンとまったく同じです
  • カスタムは、フォーマットの変更を適用した独自の「マスター」ブランチです
  • すべての機能ブランチは、上流のマスターにプルされたくない場合はカスタムから分岐されます
  • マスターが更新されたら、カスタムをマスターにリベースし、機能ブランチをカスタムにリベースします

この戦略でうまくいくはずです。ただし、カスタムに基づいて機能ブランチで行ったすべての変更が上流のマスターに受け入れられるわけではないことに注意してください。

6
Jim Martens