Githubプロジェクトをフォークし、変更しています。それぞれのタスクに対して、私は別のブランチを作成し、後でフォークのmaster
にマージします。複数のプルリクエストとしてフォークからの変更をプッシュ
だから今私は元のレポのmaster
より20コミットのような仕事にmaster
を持っています。
このプロジェクトのルールはcreate pull request for each task
です。
私はgit
でそれを行う方法を知っていますが、私はそのプロセスについてはわかりません。
2番目のコミットに含まれるタスク1のプルリクエストを作成する方法、5番目のコミットに含まれるタスク2を作成する方法などはわかりません。
私は間違いを犯しましたが、今度は複数の修正プログラムに対してのみ同時にプルリクエストを作成できますか?私はこのような
を行っている必要があります。
は
タスクを修正、元のマスターにフォークマスターからプル要求を作成するフォーク上のマスターと
をマージ?あなたが提案し何
EDIT
@OliverCharlesworthは、私が過去に働いていた方法ですが、それは多くの問題をもたらしました。最初にいくつかのタスクを修正してから、それぞれにPRを作成するので、マスターと多くの競合が生じました(無駄な)。だから私はPRを作成するたびに、自動的にマージできないというメッセージを得ましたが、最初に競合を解決しなければなりません。その後、PRの90%のために、私はマージに対処しなければならず、マージ時にだけ数時間を失いました。
これが私が間違っていると思った理由です。
"1つのタスクを修正してからマスタにマージする"というルールに切り替えたとき、私はこれらのばかげた矛盾をすべて回避し、マージ時に私たちを保存しました。
「ブランチからのPRを作成する」が正しい方法だと言うので、どうやって愚かな競合を避け、愚かなマージプロセスで数時間を失うことはありませんか?
注:私が「ばか」と言うと、すべての競合が解決しなければならない同じコードに解決されるということです。私が新しいルールに従うと決して起こらないもの。愚かなことは、「合理的な理由なしに合併して時間を失う」という意味です。
マスターブランチ(フォーク)に変更をプッシュすると、アップストリームレポで行ったプルリクエストによって、マスターブランチにあるすべてのコミットが更新および表示されます。 AFAIKは、これを避ける方法はありません。タスクごとに1つの追加ブランチを作成し、それをコミットし、すべてのブランチに対してPRを作成しない限りです。 – CoDEmanX
解決策はあなたのフォーク上でマスターにマージされません。ブランチから元のレポに戻るPRを作成します。 –
@OliverCharlesworth EDITにチェックを入れてください。コメントは長すぎました。 – sandalone