web-dev-qa-db-ja.com

GitHubプルリクエストでホットフィックスを実行する方法

警告:私はgitとGitHubの両方にかなり慣れていません。

したがって、私の現在のセットアップでは、私のチームはgit flow Hotfixes(通常、GitKrakenやIntelliJなどのグラフィカルツールによって開始および終了)を使用して、2つのブランチにマージし、両方の上流にプッシュする必要がある変更を加えます。たとえば、フローは次のようになります。

  1. マスターから最新をプル
  2. 修正プログラムを開始
  3. 変更をコミットする
  4. ホットフィックスブランチをマスターとマージの両方にマージし、両方をアップストリームにプッシュする

現在、コードをGitHubに移動することを検討しており、いくつかの理由でプルリクエストの使用を開始したいと考えています。

  • テストなどを実行するCIフック
  • 根本的な「問題」に直接関連しないコード固有のコメントを配置する場所
  • 変更をマージできるように、誰もが常に最新のマスター/開発をローカルマシンにプルする必要を回避する

しかし、Hotfixの場合、2つのブランチにマージしているため、どうすればよいかわかりませんが、実際には1つの「アクション」であるため、特に現在のフローのステップ4)から手動で2つのプルリクエストを作成するのはおかしいようです。シングルクリック。

これを処理するスマートな方法はありますか?私の理想的なケースは、プルリクエストの[マージ]ボタンを押すだけで両方にマージされることですが、これは利用可能なオプションではないようです。

34
Dan

おっしゃったように、プルリクエストにはoneターゲットブランチしかないため、ホットフィックスを両方にプッシュできませんmasterおよびdevelopは、1つのプルリクエストをマージします。

あなたがあなたのステップ#4-hotfixブランチをmasterdevelopの両方にマージし、上流にプッシュする-が1つのアクションであることに言及して驚いています。 hotfixからmasterへのマージがマージの競合に遭遇しない可能性は高いですが、hotfixからdevelopは、本番環境への最後のデプロイ以降に対応できた可能性があるためです。

私の推奨は次のようになります:

  • hotfixからmasterまでのPRを1つ作成し、誰かがそれをレビューして修正を検証する
  • masterにマージされたら、hotfixからdevelopへの別のPRを作成し、マージの競合が発生するかどうかを確認します
    • その場合は、マージの競合を解決して、PRがマージされる状態になり、誰かにPRをレビューしてもらいます。
    • マージの競合がない場合は、誰かにPRをレビューしてもらいます

自動化された道を進みたい場合の代替ソリューションは、GitHub WebhookとAPIの両方を活用することです。

Webhookを使用すると、 PRがマージされたときに通知される になります。ペイロードを調べて、ベースブランチがhotfix/で始まり、ターゲットブランチがmasterであることを確認できます。次に、同じhotfixブランチからdevelopへのAPIを使用して 新しいPRを作成 することで、そのイベントに反応できます。

これにはある程度の開発が含まれますが、UIを介したPRの作成は非常に簡単で迅速であるため、この作業は価値がないかもしれません。

30