私たちのチームは、こちらで説明されているように、Github プル リクエストを使用してワークフローを管理しています。承認されたプル リクエストを手動で確認すると、本番サーバーにデプロイする準備ができていないため、マージを元に戻す必要がある場合があります。
ただし、開発者が再度プル リクエストを発行しようとすると、これらの変更が元に戻されたことを認識せず、コミットが既にマスター ブランチにあることがわかります。元に戻してからの最近のコミットのみが含まれますが、私たちが本当に望んでいるのは、元に戻されたすべてのコミットと彼らの新しい作業を再紹介することです。言い換えれば、元のプル リクエストを再発行する方法が望ましいということです。
Github はこの機能をサポートしていないため (つまり、マージを元に戻したり、元のプル リクエストを元に戻したり再発行したりすることはありません)、現在、元に戻したマージを元に戻しています。これは間違っていると感じます。
git で同じ目標を達成するために他にどのような方法を使用できますか? （または可能であればGithub）
プル リクエストを処理するときに、GitHub でそれらを自動的にマージすることを選択しているため、ここで問題が発生すると思います。ドキュメントに記載されているプル リクエストを処理する 3 つの提案された方法のうち、最近実装されたばかりの最後の方法 (「自動マージ」) を使用しています。個人的には、これは明らかに正しい単純なプル リクエストにのみ適していると思います。より複雑なものについては、最初のアプローチを使用したいと思います。
つまり、マージされたバージョンは、テストしてプッシュすることにした場合にのみ公開されます。そうしたくない場合は、マスター ブランチを以前の位置にリセットするだけです。
興味深いことに、残念なマージを元に戻さなければならなくなったが、そのブランチの新しいバージョンを再マージするオプションが必要な場合に何が起こるかについて、さらに説明する価値があるかもしれません。間違っていると感じるかもしれませんが、私が理解しているように、そのような状況に対処する最も簡単な方法は、実際にリバートをリバートすることです。この問題の詳細については、Pro Git ブログのこの投稿と、参考になるかもしれない Linux Torvalds による同じ問題の別の議論を参照してください。
別のアプローチを取ることをお勧めします。元に戻すワークフローと元に戻すワークフローは、私には非常に混乱しているようです。あなたが解決しようとしている実際の問題は、別の方法で取り組むことができます。
2つのブランチを使用するようにワークフローを変更することをお勧めします。1つの安定したブランチ（master）と1つの開発ブランチ（develop）。すべての作業は、developブランチまたは個別のトピックブランチに送られます。プルリクエストは常にブランチに対して提出され、承認されたときにdevelopマージされます。develop
master最初はから分岐していdevelopます。安定した状態になったらすぐにdevelop、にマージしmasterます。master現在の安定したリリースです。
これは、 nvieの「成功したGit分岐モデル」に大まかに基づいています。
機能ごとのブランチ連隊が進行している場合は、好きな機能でリリース候補を再構築できます。「マージを元に戻す」必要はありません。
さらに読む: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
追加の洞察については、コメントも参照してください。それは私たちにとって本当にうまくいきます。