2016-08-25 2 views
1

Githubプロジェクトをフォークし、変更しています。それぞれのタスクに対して、私は別のブランチを作成し、後でフォークのmasterにマージします。複数のプルリクエストとしてフォークからの変更をプッシュ

だから今私は元のレポのmasterより20コミットのような仕事にmasterを持っています。

このプロジェクトのルールはcreate pull request for each taskです。

私はgitでそれを行う方法を知っていますが、私はそのプロセスについてはわかりません。

2番目のコミットに含まれるタスク1のプルリクエストを作成する方法、5番目のコミットに含まれるタスク2を作成する方法などはわかりません。

私は間違いを犯しましたが、今度は複数の修正プログラムに対してのみ同時にプルリクエストを作成できますか?私はこのような

を行っている必要があります。

  • タスクを修正、元のマスターにフォークマスターからプル要求を作成するフォーク上のマスターと

  • をマージ?あなたが提案し何

EDIT

@OliverCharlesworthは、私が過去に働いていた方法ですが、それは多くの問題をもたらしました。最初にいくつかのタスクを修正してから、それぞれにPRを作成するので、マスターと多くの競合が生じました(無駄な)。だから私はPRを作成するたびに、自動的にマージできないというメッセージを得ましたが、最初に競合を解決しなければなりません。その後、PRの90%のために、私はマージに対処しなければならず、マージ時にだけ数時間を失いました。

これが私が間違っていると思った理由です。

"1つのタスクを修正してからマスタにマージする"というルールに切り替えたとき、私はこれらのばかげた矛盾をすべて回避し、マージ時に私たちを保存しました。

「ブランチからのPRを作成する」が正しい方法だと言うので、どうやって愚かな競合を避け、愚かなマージプロセスで数時間を失うことはありませんか?

注:私が「ばか」と言うと、すべての競合が解決しなければならない同じコードに解決されるということです。私が新しいルールに従うと決して起こらないもの。愚かなことは、「合理的な理由なしに合併して時間を失う」という意味です。

+1

マスターブランチ(フォーク)に変更をプッシュすると、アップストリームレポで行ったプルリクエストによって、マスターブランチにあるすべてのコミットが更新および表示されます。 AFAIKは、これを避ける方法はありません。タスクごとに1つの追加ブランチを作成し、それをコミットし、すべてのブランチに対してPRを作成しない限りです。 – CoDEmanX

+1

解決策はあなたのフォーク上でマスターにマージされません。ブランチから元のレポに戻るPRを作成します。 –

+0

@OliverCharlesworth EDITにチェックを入れてください。コメントは長すぎました。 – sandalone

答えて

3

タスクを自分のforkしたリポジトリにプッシュし、それらのブランチに対してプルリクエストを開くだけです。任意のブランチXの任意のブランチへのプルリクエストを作成することができます。Ymasterからmasterへのプルリクエストを作成する必要はありません。

+0

私のEDITをご覧ください。私はこれを過去に行い、愚かな合併で数時間を費やすたびに終わった。 – sandalone

+2

タスクブランチからのPR **は**への道です。ブランチを 'master'にマージし、そこからプルリクエストを開くと、同じマージ競合が発生します。あなたのブランチをプッシュしてPRを開く前に、あなたは上流からフェッチし、あなたのフィーチャーブランチを 'upstream/master'の上にリベースしなければなりません、そして、PRは矛盾しません。 – Vampire

+0

最も時間のかかることは、私がPRを統合したときにマスターと同じ競合を処理しなければならないということでした。毎回同じものや同じものを2時間に渡ってマージするのは非常にイライラしました。 – sandalone

関連する問題