GitHub：マージされたプルリクエストを再度開く

101

変更を加えました
プルリクエストを送信しました
プルリクエストが受け入れられ、マージされました。
バグを見つけました
バグを修正する間、変更は再び削除されました。

バグを修正したので、プルリクエストを1回余分にコミットして再送信します。プルリクエストを再度開いたり更新したりする方法はありますか、または新しいプルリクエストを作成したり、説明をもう一度入力したりする必要がありますか？Gitoriousにはこの機能があり、最近GitHubに移動しました。

github merge pull-request

— マイケル・パーカー
ソース

私は今日同様の状況にありました。つまり、デフォルトで変更をターゲットブランチにマージし、PRを閉じる「Merge Pull Request」ボタンを使用しました。後で、元の開発者に修正してほしいテストのバグを発見しました。この同じPRにさらにコミットを追加できるように、このPRを再度開く方法が必要でしたが、PRを再度開くためのボタンがないため、できませんでした。

— SBirthare 2016

114

答えは次のようです：できません。

プルリクエストがマージされて閉じられると、永久にロックされ、再度開くことはできません。プルリクエストがマージされて閉じられ、変更がプルされる場合（マージの前に強制的に後方にプッシュすることにより）、ブランチにコミットを追加して新しいプルリクエストを作成し、すべての詳細をコピーして、おそらく提供する必要があります手動で履歴を保存するための元のプルリクエストへのリンク。

将来のGitHubに対する機能のリクエストになるかもしれません。

— マイケル・パーカー
ソース

8

いつ変更されたのかはわかりませんが、閉じたPRをコメントして再開できます。

— LB-- 2013

16

@LB、閉じられてマージされたPRを再び開くことはできないようです。

— Kaptur 2013年

1

あなたは実際にできます。最初のマージを元に戻したと想定して、メインリポジトリのブランチを作成し、この新しいブランチでマージを元に戻していたコミットを元に戻すことができます。

— SsjCosty

7

@SsjCostyしかし、それは閉鎖されマージされたPRを再開するものではありません。ソリューションに必要な新しいプルリクエストをいつでも開くことができます。

— アダムグラント

1

「将来のGitHubの機能のリクエストになるかもしれません。」 実際には、そうではありません。作成後にPRを再定義できる場合、人々がさまざまなタイミングでPRをチェックアウトすると、ドリフトする可能性があります。別のPRを作成し、前のPRをテキストで「言及」するだけです。ある種のマイルストーンを参照したい場合は、PRでなく、タグになります。

— Scott Prive

12

私はプルリクエストを正常に再開しました

プルリクエストにコメントする
コメントフォームに表示された[送信して再度開く]ボタンをクリックします。

— ティム・ロヴェル・スミス
ソース

1

これを再現することができませんでした-この動作を確認するために必要な手順を説明できますか？クローズドプルリクエストにコメントし（didnt work）、クローズドプルリクエストにコメントし、プルしたブランチにプッシュしました（didnt work）。他に試すことはありますか？プルリクエストをマージして、後でなんとかしてマージ解除する必要がありますか？

— マイケルパーカー、

違いを生む隠れた要件が何かはわかりません。（プルリクエストの新しい変更を提出した、プロジェクトオーナーのメンバー、その他...）

— Tim Lovell-Smith

1

私はあなたが言及したすべてを試しましたが、まだそれを見ることができません。私はリポジトリの所有者です。googleで「送信してGitHubを再度開く」を検索すると、1つのヒット-このページが表示されます。それ以上の情報は非常に役に立ちます。あなたのプルリクエストは最初に拒否されましたか？

— マイケルパーカー

52

マージされていないプルリクエストでこれを複製できますが、それはこのスレッドの目的ではありません。

— Dan Tello

2

ええ、彼はマージされたプルではなく、クローズされたプルについて言及しています。

— loujaybee

4

追加の1コミットを実行した既存のブランチから新しいブランチを派生させるだけです。そこからプルリクエストを送信します。

— シバゴラパリ
ソース

3

これにより、元の履歴のない新しいプルリクエストが作成されます。

— Dave

1

これは私がやったことです。はい、歴史はそれほど直線的ではありませんが、私にとっては大丈夫です。

— possen

4

元に戻すアクションを使用できます。

マージされたPRで行われたすべての変更を元に戻す別のプルリクエストを作成します。

— ウィリアム・ウェックル
ソース

これはベストプラクティスではありません:)

— antonbormotov 2017

2

@antonbormotovより良いアプローチを提案できますか？

— William Weckl

prとコミット（mAおよびmB）をマージして、元に戻したい安定したブランチにしたとします。「元に戻す」PRをマージすると、履歴はコミットツリーのようになります：XY-mA-mB-CD-rA-rB-EF。変更を適用（mA、mB）してからそれらをキャンセル（rA、rB）するこれらすべてのコミットを履歴に表示するのはなぜですか？これらの「悪い」コミットmAとmBを安定したブランチからリベースして削除し、履歴をクリーンに保つことをお勧めします。もちろん、マージが比較的最近だった場合は理にかなっています。

— antonbormotov

1

履歴が見苦しく見えるだけでなく、準備ができたときに元に戻されたコミットを単純にマージすることもできなくなります。

— マイケル

少し違いはありますが、似たようなシナリオでした。レビューが必要なPRがあり、別のPRがマージされるのを待つことになっていた。しかし、私はそれを見ていないため、このPRを時期尚早にマージしました。私は実際には@WilliamWecklが提案したことをしました。しかし、私は最初に作成されたものと同じ変更を加えた同じPRを作成したいと思います。しかし、私がPRを作成しているとき、masterブランチは違いを示していませんが、個々のファイルを見ると、違いがあります。何かご意見は？

— Vikas