Part 2 開発の基本動作・動画
第6章 変更をレビューにつなげる
動画台本ナレーション全文
Slide 01. 変更をレビューにつなげる
第6章では、手元で行った変更を、チームにレビューしてもらいやすい形にします。第5章では、アプリを動かし、ログを読み、作業を記録しました。この章では、その作業をGitの履歴に残し、GitHubのPull Request、略してPRで共有します。コードを書いたあと、何を変えたのか、なぜ変えたのか、どう確認したのかを、相手に渡せるようにします。
Slide 02. この章で持ち帰ること
この章でできるようになるのは、変更をレビューしてもらいやすいまとまりにする流れです。現在地を確認する。branchを作る。差分を見る。commitする。PRに背景と確認方法を書く。レビューコメントに返す。全部を一度に覚えなくて大丈夫です。まずはこの順番で見ることを身につけます。
Slide 03. 前の章の成果をPRへつなぐ
第4章の変更説明メモは、PR本文の材料になります。第5章のローカル実行ログは、確認方法の材料になります。第6章では、この2つを使って、差分だけを見せるのではなく、背景、変更内容、確認結果、レビューしてほしい点までセットで渡します。
Slide 04. GitとGitHubの役割
Gitは、手元で変更履歴を管理する仕組みです。GitHubは、その履歴をチームで共有し、PRやレビューを行うサービスです。たとえるなら、手元で編集して保存する仕組みと、チームに共有して見てもらう場所は役割が違います。Gitでcommitを作り、GitHubでPRを出す、と分けて考えます。
Slide 05. Git側とGitHub側の用語
ここでは、用語を全部覚える必要はありません。まずGitでは3つだけ見ます。working treeは、いま編集している状態。staging areaは、次のcommitに入れる変更を選ぶ場所。commitは、選んだ変更を履歴に残す単位です。branchやremote、GitHub側のrepository、PR、mergeは、このあとの流れで確認します。
Slide 06. 作業前の現在地確認
Git操作を始める前に、どのrepository、つまりどの作業場所で、どのbranchにいて、commitしていない変更があるかを見ます。git statusは、Gitで作業するときの現在地確認です。ここを飛ばすと、違うbranchで作業したり、関係ない変更を混ぜたりしやすくなります。まずは現在地を見る習慣を作ります。
Slide 07. diffを読む
git diffは、まだcommitしていない変更の中身を見るために使います。差分は、追加された行、削除された行、変わったファイルを教えてくれます。commitする前に、自分の差分を読みます。AIが作った変更でも、自分の変更として説明できるかを確認します。
Slide 08. branchで作業を分ける
branchは、mainを直接変えずに、作業用の枝を作るための仕組みです。main branchには、基本的に安定した状態を置きます。新しい機能、バグ修正、ドキュメント更新は、それぞれ目的に合ったbranchで進めます。1つのbranchに複数の目的を混ぜると、レビューが難しくなります。
Slide 09. 良いbranch名
branch名は、作業内容が分かる名前にします。新機能なら feature/progress-empty-state。バグ修正なら fix/submission-filter。ドキュメントなら docs/update-setup-guide。名前が具体的だと、自分もレビュアーも、何の作業かを思い出しやすくなります。
Slide 10. commitは小さな変更単位
commitは、選んだ変更をGitの履歴に残す単位です。作業の途中保存というより、あとから読める変更履歴だと考えます。1つのcommitには、できるだけ1つの意図を持たせます。たとえば、空状態の案内文を追加するcommitと、別のフィルタ仕様を変えるcommitは分けます。良いcommitは、未来の自分やチームが変更理由を追いやすくします。
Slide 11. commit前チェック
commit前には、変更したファイルが意図どおりか、関係ない変更が混ざっていないか、APIキーやトークンなどの秘密情報が入っていないかを確認します。手元で確認した結果も書いておきます。commit messageは、何を変えたかが分かる短い説明にします。
Slide 12. Pull Requestとは何か
Pull Requestは、branch上の変更をチームに見せ、レビューしてもらう単位です。略してPRと呼びます。PRは、コード差分を置くだけの場所ではありません。背景、変更内容、確認方法、リスク、レビューしてほしい点をまとめ、レビュアーが見てよいか、直す必要があるかを決められるように材料をそろえる場所です。
Slide 13. PR本文の型
PR本文では、まず背景、変更内容、確認方法、レビューしてほしい点を書きます。余裕があれば、今回やらないこと、影響範囲、リスクも添えます。AIを使った場合は、AIの案をそのまま貼らず、自分で確認したことを残します。第4章のchange-description.mdを土台にし、第5章のlocal-run-log.mdから確認方法を持ってきます。
Slide 14. 悪いPRと良いPR
レビューしづらいPRは、進捗一覧を直しました、だけで終わります。これでは、なぜ直したのか、何を変えていないのか、どう確認したのかが分かりません。レビューしやすいPRでは、背景、変更内容、確認方法、レビュー観点を分けて書きます。レビュアーが見るべき場所を選べるようにします。
Slide 15. セルフレビュー
レビューを依頼する前に、自分で差分を読みます。まず3つ見ます。変更目的と差分が合っているか。関係ない変更や秘密情報が混ざっていないか。手動確認やテスト結果を書けているか。権限、データ、ユーザー影響が関わる変更なら、その点も見ます。まず自分で見ることで、レビューの質が上がります。
Slide 16. コードレビューの流れ
コードレビューは、間違い探しだけではありません。変更を安全に取り込むための確認です。レビュアーは、差分、背景、確認方法、リスクを見ます。コメントが来たら、必要に応じて修正し、再確認し、返信します。承認されたら、チームのルールに沿ってmergeへ進みます。
Slide 17. レビューコメントへの返し方
レビューコメントへの返し方は、修正する、質問する、今回は別PRにする、代替案を出す、に分けられます。まず、指摘をどう理解したかを書きます。修正するなら、何をどう直したかと確認結果を書きます。今回は扱わないなら、PRの目的から外れることや、別で対応する理由を短く書きます。反論だけで終わらせず、次に何をするかが分かる返信にします。
Slide 18. 追加commitで対応する
レビュー後の修正は、追加commitとしてPRに追加します。修正したら、もう一度差分を確認します。返信では、どのコメントに対して、何を変え、どう確認したかを短く残します。レビュー対応も履歴の一部です。あとからPRを読んだ人が判断の流れを追えるようにします。
Slide 19. conflictの考え方
conflictは、Gitが自動では判断できない変更がある状態です。失敗というより、人間の判断が必要というサインです。同じ場所を別々のbranchで変えたときなどに起きます。画面には、<<<<<<< のようなconflict markerが出ることがあります。目的はmarkerを消すことではなく、両方の変更意図を理解して、正しい最終状態にすることです。
Slide 20. 履歴を読む
Gitの履歴は、過去の判断を読むためにも使います。git logでcommitの流れを見る。git showで特定commitの差分を見る。GitHubのPR会話やレビューコメントも判断の履歴です。既存コードを変える前に履歴を見ると、なぜ今の形になっているのかを理解しやすくなります。
Slide 21. AIをGitとGitHubに使う
AIは、差分の要約、commit message案、PR本文の下書き、レビュー観点の洗い出しに使えます。使う前に差分を読み、採用前に実際の変更と合っているか確かめます。PRには、実行していない確認を書きません。reset、clean、push –forceなど、ファイルを戻す、消す、履歴を上書きする操作は、意味が分からなければメンターに相談します。
Slide 22. 演習1 repositoryの現在地
最初の演習では、演習用repositoryの現在地を確認します。使うのは主にpwd、git status、git branch、git remoteです。見るのは、作業場所、branch、commitしていない変更、remoteの4つです。成果物の git-work-log.md には、確認結果とメンターに聞きたいことを書きます。
Slide 23. 演習2 branchとcommit
次の演習では、小さな変更をbranchで分け、commitにします。題材は、進捗一覧が空のときの案内文です。作業用branchを作り、変更を入れ、git diffで差分を読みます。commitに入れる変更を選び、関係ない変更や秘密情報がないことを確認してcommitします。branch名、変更内容、commit message、確認結果を記録します。
Slide 24. 演習3 Pull Request作成
3つ目の演習では、branchをGitHubへpushし、Pull Requestを作ります。第4章のchange-description.mdから背景と変更内容を使い、第5章のlocal-run-log.mdから確認方法を持ってきます。レビューしてほしい点も1つ書きます。成果物は PR URL と pull-request-note.md です。
Slide 25. 演習4 レビュー対応
4つ目の演習では、進捗一覧の文言修正PRに届いたレビューコメントへ対応します。たとえば、担当受講者0件とフィルタ結果0件を分けるべきか。文言を自然にできるか。未提出者フィルタも同じPRに含めるか。コメントを、修正する、質問する、今回は別PRにする、に分け、理由と返信案を書きます。成果物は review-response-log.md です。
Slide 26. 演習5 conflictと履歴確認
最後の演習では、conflict例と履歴確認を扱います。conflict markerで区切られた上側の変更と下側の変更が、何を意図しているかを読みます。2つの状態が同じなのか、別物なのかを考えます。git log、git show、PR会話から判断材料を探す流れも書きます。成果物は conflict-and-history-note.md です。
Slide 27. 次はWebの仕組みへ
第6章では、変更をbranch、commit、Pull Request、レビュー対応として扱う流れを学びました。第7章からは、画面、ブラウザ、HTTP、サーバーの関係を見ます。そこで観察した結果も、相談やPRの確認方法に使える材料になります。これからの変更も、手元で動かし、Gitで履歴に残し、GitHubでレビューできる形にしていきます。