やさしいGitとGitHub
第4章 チームで共同作業する
14 / 18
LESSON 4-4

レビューと
マージ

変更の中身を確認して、問題なければ本流に取り込みます。ダブルチェックと、本帳簿への反映にあたる、大切な場面です。

所要時間約8分必要なものなし（図を見るだけ）難しさふつう

このレッスンでわかること

まず言葉の意味からレビューは「ダブルチェック」、
マージは「本帳簿への反映」

レビュー（review）は、変更の中身を確認して、意見や承認を伝えることです。経理でいえば、ダブルチェックです。起案した人とは別の人が、中身を見て確かめます。

マージ（merge）は、確認が済んだ変更を、本流に取り込むことです。承認が下りたあとの、本帳簿への反映にあたります。

手順3つのステップで進めます

01

変更の中身を見る

プルリクエストの画面で、Files changed のタブを開くと、どこがどう変わったかを確認できます。緑が足した行、赤が消した行です。

  1. 1
    Files changed：「変更されたファイル」。変更の中身を見るタブです。
  2. 2
    緑の行：新しく足された部分です。
02

レビューを送る

内容を確認したら、レビューを送ります。選択肢は3つあります。

  1. 1
    Review changes：「変更のレビュー」。ここから、確認の結果を選んで送ります。
  2. 2
    Approve：「承認」。問題なければ、これを選びます。
  3. 3
    Commentは「コメントだけ」、Request changesは「直してください」という意味です。
ここだけ注意自分で出した変更を、自分だけで承認しないでください。ダブルチェックの意味がなくなります。必ず、別の人に確認してもらいましょう。
03

本流に取り込む（マージ）

承認が済んだら、Merge pull request を押します。もう一度、確認のボタン（Confirm merge）が出るので、押すと、変更が本流に取り込まれます。

  1. 1
    Merge pull request：「プルリクエストをマージする」。押すと、確認のボタンが出ます。
用語メモ：ブランチの片づけマージが済んだブランチは、役目を終えます。GitHubが「ブランチを削除しますか」と聞くことがありますが、取り込み済みの下書きの枝を片づけるだけで、記録は本流に残ります。

まとめ

  1. レビューは、変更の中身を確認するダブルチェック
  2. 問題なければ承認（Approve）し、マージで本流に取り込む
  3. 自分の変更を、自分だけで承認しない

※ 画面図は実際の画面を簡略化したものです。実際の画面とは細部が異なる場合があります。この章は、練習相手がいなくても学べるよう、図と流れを中心にしています。