4

私は github プロジェクトに貢献していますが、ちょっと困っています。

元のレポに新しいフィーチャー ブランチがあり、積極的にプル リクエストを送信します。継続的にプル リクエストを送信し、マージを待ってからフォークのブランチを削除し、更新されたコードベースから新しいフォークを作成する必要はありません。私の質問は、これを行うための最良の方法です。

明確化の例:
main = 元のレポ
mine = 私のフォークされたレポ
main は機能ブランチを作成しました。
その機能ブランチを自分のものにフォークしました。
私は自分のものに変更を加え、プルリクエストを送信しました。
メインは私のプルリクエストをマージしました

私の質問: 以前のプル リクエストと重複するプル リクエストを避けるために、私のものを削除して機能ブランチを再度フォークする必要がありますか、それともこれを達成するためのより良い方法はありますか。

更新 実際の例として、私は codeigniter フレームワークに取り組んでおり、認証システムに大きな変更があります。元のレポでは、このために新しい機能ブランチが作成されました。私の懸念は、まだ問題はありませんが、非常に流動的で急速に変化するブランチであることです。したがって、私の質問を拡大すると、それは一連の修正ではなく、進行中の多数の修正です。

4

1 に答える 1

1

良い質問!まず、(プロジェクトのメンテナー / プル リクエストを受け入れる予定の人物) と会話をして、彼または彼女の好みを調べます。私を信じてください、あなたはメンテナの生活を楽にし、あなたが正しいことをしていると彼に確信させたいのです. 彼のプル リクエスト ワークフローを快適なものにすることは、大いに役立ちます。

では、あなたが行っている変更 (およびプル リクエスト) の性質は何ですか? それらは「名前付き機能」ですか、それとも「小さな」バグ修正の集まりですか?

また、触れている行に大きな重複がありますか (プル リクエスト間でマージの競合が発生する可能性があります)、またはそれらはほとんど直交していますか?

それらが「名前付き機能」であり、オーバーラップ/マージの競合がほとんどない場合、私は機能ごとに 1 つの新しい名前付きブランチを貼り付けます。オーバーラップがある場合、および/またはそれらが小さなバグ修正である場合、メンテナーがOKであれば、おそらく「単一のフォークされたブランチからの継続的なプルリクエスト」を使用します。

あなたはこれを知っているかもしれませんが、後世のために入れています。git ブランチは安い、安い、安い。疑わしい場合は、新しいブランチを作成してください。

于 2013-09-16T04:18:19.730 に答える