チーム開発で必須のGit/GitHubをマスターする実践練習法

一人で使っているうちは、何も困らない

個人開発で Git を使っていると、やることは add と commit と push の三つだけです。ブランチも切らず、main に直接コミットし続けても、誰にも迷惑はかかりません。困らないので、それで十分に見えます。

詰まるのはチームに入った瞬間です。「まず作業ブランチ切ってね」と言われ、切ったつもりが main に積んでいた。プルリクエストを出したら「差分が大きすぎて読めない」と返された。git pull したら見たことのない <<<<<<< という記号がファイル中に現れて、手が止まった。技術的に難しいことは何もしていないのに、進めなくなります。

チーム開発の Git は、履歴を残すツールではなく変更を他人に説明するための道具です。そこだけ押さえれば、詰まる場所はブランチ、レビュー、衝突の三つに絞れます。

ブランチは、失敗を隔離するための箱

作業ブランチを切る理由は、履歴を綺麗にするためではありません。まだ完成していない変更を、他の人が動かしている main から切り離しておくためです。箱の中でなら、途中で全部消してやり直しても誰も困りません。

一人でこれを練習するには、練習用リポジトリを作り、どんなに小さな変更でも必ずブランチを切ってから触る、という縛りを一週間続けるのが早いです。README の一行を直すだけでもブランチを切る。手が勝手に動くようになれば、現場で切り忘れることはなくなります。

もう一つ、ブランチは小さく保ってください。一つのブランチに三つの機能を詰め込むと、レビューする人はどこからどう読めばいいのか分からなくなり、返事が遅くなります。返事が遅いと自分の手も止まるので、結局は自分が損をします。

レビューで読まれているのは、コードより先に説明

プルリクエストを出すと、レビュアーはまず説明文を読みます。差分を見る前に「何のための変更か」を知りたいからです。ここが空欄だと、レビュアーはコードから意図を推測する作業から始めることになり、そのぶん時間がかかります。

説明に入れておきたいのは、何を直したか、なぜ直したか、どう確認したか、の三点です。「ログイン後に前のページへ戻らない問題を直しました。リダイレクト先をセッションに保存する方式に変えています。Chrome と Safari で、ログイン前に閲覧していた記事へ戻ることを確認しました」。この程度で十分です。

指摘を受けたときは、修正コミットを積み足せば大丈夫です。作り直して出し直す必要はありません。指摘に納得できない場合も、黙って直すより「こう考えて今の形にしましたが、どうでしょうか」と書いたほうが議論が早く終わります。レビューは合否の判定ではなく、二人で仕様を確かめる場です。

衝突は、平時にわざと起こしておく

同じ行を二人が別々に書き換えると、Git は自動で合流できず衝突します。初めて見ると壊れたように感じますが、壊れないように Git が手を止めてくれている状態です。どちらを残すかを決められるのは人間だけなので、判断を求められているにすぎません。

怖さは、締め切り前に初めて遭遇するから生まれます。余裕のあるうちに、自分で起こして直しておきましょう。

衝突したファイルを開くと、<<<<<<< から >>>>>>> までの間に両方の内容が並んでいます。残す側を選んで記号ごと消し、保存してコミットすれば終わりです。これを三回繰り返すと、現場で遭遇しても手が止まらなくなります。

ブランチを切る、説明を書いて出す、衝突を自分で直す。この三つが体に入っていれば、チームで働く準備はできています。