Gitのマージについて

Question

確認したいこと

①開発環境で改修したPRをマージし、本番環境にPRをだしました。(第三者に見てもらうため)
②第三者に確認していただいたPRが4つほどたまりました。(４つともマージOK)
③本番環境にマージするため、1つのPRごとマージボタンを押した場合、残りの3つの改修とごちゃごちゃにならないのでしょうか？

(初めに開発環境で本番環境のブランチをcheckoutし改修しているのですが、1つのPRをマージすること本番のコードが更新されてしまい、のこりの3つのPRをマージするときに差分が発生するかとおもいました)

Answer 1

PRという名前から察するにGitHubでしょうか？
まぁ、BitBucketでもGitLabでもプルリクエストという名称が、
マージリクエストという名称に変化する程度で中身は似たりよったりなので、

今回はGitHubのプルリクエストだと思って解説していきます。

③本番環境にマージするため、1つのPRごとマージボタンを押した場合、残りの3つの改修とごちゃごちゃにならないのでしょうか？

Gitのマージ機能は非常によく出来ており
ぐしゃぐしゃにならない限りは賢くマージをしてくれます。

もし挙動がぐしゃぐしゃになりそうな時は
「コンフリクトしています！人間が確認してください」とアラートを出してくれます。
これにより、全く同じファイルの同じ行が干渉しない限りはすんなりと通ります。

これで整合性が合わないようなコードはそもそも書くなって話で、
それなりにプログラミングの腕のある人がレビューして通るって事はそのへんはあまり心配する必要はないかと思います。
（信頼出来ないならテストコード書いてGitHub Actions等で自動テストしろ）

そしてこの「コンフリクトが出そうだよ！」アラートは黄色信号と共に非常に目立つ表示になるので、
余程寝ぼけてる奴しか見ないでマージするなんて有り得ません。

---

今回の例でいうと
GitHub上にプルリクエストが4個あります

レビュワーが1個目のプルリクエストの画面で承認して、
マージボタンをクリックします。

その時点で残り3個のプルリクエストは、
マージ後の新ブランチへのマージ要求に変化します。

レビュワーさんが2個目のプルリクエストに画面遷移したら、
コンフリクトが出そうなら「コンフリクトが出るのでマージ出来ませんよ！」
という事を示す「黄色いアラート」が画面上に表示されます。

なので余程無頓着な人でなければ、
黄色のアラートが出た画面で「マージ」ボタンを押そうとはしないはずです。

2個目のプルリクエストを承認されてマージされたら、
コンフリクト等が発生しそうな場合教えてくれます。

---

ブランチ運用ルールのgit-flowなんかだと
Gitのマージは99％は信頼しているんだけど、
念の為本番リリース前に挙動を確認しておきたいよねという考えです。

なので、masterブランチに向けて直接マージしまくるのではなく、
一度developmentブランチに向けてプルリクエスト→マージを集中させておき……

リリースのタイミングでそのdevelopmentブランチを一度全体的にテスト・動作検証をして、
動作検証をパスしたら晴れてmasterブランチへマージされて本番運用という流れを辿ります。

このgit-flowは100％そのまま運用するかはさておき、
これを参考にした上で、自分なりにカスタマイズしたような運用をなされているはずです。

---

今回の質問では既に確立されたブランチ運用ルールが決まっている現場ではないでしょうか？
それに従っておけばまぁ間違いないと思います。

私はgit-flowの全体像なんかは説明出来ますが、
質問者さんのチームがどこをどう運用しているかなんて知るわけがないので細部は答えられません。

もし運用ルールとしてこの辺どうなってるんだろう？
という質問があれば先輩等に質問してみてください。

むしろ知らない人間が開発メンバーに居るって良くない状況ですから、
先輩達も快く教えてくれるはずです。

Comments

[退会済みユーザー]

ありがとうございました！

Answer 2

ちょっと状況がわかりづらいです。開発環境、本番環境というのは、それぞれ専用のブランチを作って運用しているということでしょうか？

• どんなブランチがあるのか
• それらのブランチをどう運用しているか
• 使っているソースコード管理サービスは何か

このあたりの情報があれば回答集まると思います。