非開発者のための IT 常識 #5 Git とバージョン管理 — 複数人で一つのコードを直す方法
前回の記事で、新しいデプロイが問題を起こしたときに、直前の正常なバージョンへ戻すロールバックについて話しました。そのとき、一つの疑問を残しておきました。戻すための以前のバージョンは、いったいどこに保管されているのでしょうか。そして、複数人の開発者が同じコードを同時に直すのに、どうやってお互いの作業を上書きせずにいられるのでしょうか。
この二つの疑問の答えこそが Git とバージョン管理です。開発者が一日に何十回も「コミットしました」「プッシュしました」「マージで衝突しました」「PR をレビューしてください」と言う、あの話です。シリーズ最後となる今回の記事では、Git とは何で、なぜすべての開発チームがこれを使うのかを見ていきます。
今回のシリーズは 非開発者のための IT 常識 の全 5 編で構成されます。
- #1 ウェブサイトは何でできているのか — フロントエンド・バックエンド・データベース
- #2 API とは何か — サービス同士が会話する約束
- #3 サーバー、クラウド、そしてデプロイ
- #4 バグ、ホットフィックス、ロールバック — 開発者が障害に対応する方法
- #5 Git とバージョン管理 — 複数人で一つのコードを直す方法 ← この記事
バージョン管理は変更履歴を体系的に残すことです #
文書を作っているうちに、「企画書_最終.docx」「企画書_最終_本当に最終.docx」「企画書_最終_v3.docx」のようにファイルを増やしてしまった経験があるはずです。どれが本当の最新なのか分からなくなり、昨日消した一文をもう一度よみがえらせたくても、これといった方法がありません。
コードはこれよりもはるかに複雑です。ファイルが数百個に及び、複数人が同時に直します。そこで、誰がいつ何をなぜ変えたのかを自動的に記録し、望む時点へいつでも戻せるようにする方法が必要になります。これがバージョン管理です。
Git はコードの変更履歴を管理する道具です #
Git は、今日もっとも広く使われているバージョン管理の道具です。コードが変わるたびに、その変更を記録として残し、誰がどの部分をどう直したのかを追跡します。そして、必要なら過去のどの時点へでも戻せます。
前回の記事で見たロールバックが可能なのも、まさにこのためです。Git が変更履歴を一つずつ積み上げておくので、問題が起きた新しいバージョンを引っ込め、直前の正常だったバージョンへ素早く戻れます。バージョンが記録されていなければ、戻る先もありません。
コミットは変更を一つのまとまりとして保存する単位です #
Git で変更を保存する基本の単位を、コミットと呼びます。意味のある変更を一つにまとめて、「ログインバグ修正」のような短い説明とともに保存することです。写真を撮ってその瞬間を残すように、コミットはコードの特定の瞬間を記録として残します。
このコミットが時系列で積み上がったものが、すなわち変更履歴です。「プッシュしました」という言葉は、自分のコンピュータに積み上げたコミットを、みんなが共有するところに上げたという意味です。ロールバックは、こうして積み上がったコミットのうち、問題が起きる前の一つの時点へ戻ることです。
ブランチとマージで複数人が同時に作業します #
複数人が同じコードを同時に直すと、お互いの作業がぶつかることがあります。Git はブランチという方法で、この問題を解きます。
ブランチは、メインブランチから枝分かれした作業用の枝です。各開発者は自分のブランチで、他の人を気にせず思う存分作業します。そして作業が終わると、その変更をメインブランチに合わせるのですが、これをマージと呼びます。「マージで衝突しました」という言葉は、二人が同じ部分をそれぞれ違うように直してしまい、どちらを選ぶかを人が直接整理しなければならない状況を意味します。
GitHub は一緒に作業するオンラインの場です #
ここで、Git と GitHub を区別しておく必要があります。Git は変更を管理する道具で、GitHub はその Git リポジトリをオンラインに置き、複数人が一緒に作業できるよう手助けするサービスです。道具と、その道具を使う場の関係だと考えればよいです。
GitHub でよく登場する言葉が PR、つまりプルリクエストです。「私が作った変更をメインブランチに合わせてください」と上げる依頼です。同僚たちはこの依頼に含まれた変更を見て、意見を残すのですが、この過程をコードレビューと呼びます。レビューを通過して初めて、変更がマージされます。すぐに合わせず、もう一度確認するこの手順が、ミスを大きく減らしてくれます。
なぜ非開発者が知ると仕事が楽になるのか #
Git の大きな絵が分かると、開発チームの働き方が見えてきます。
- 開発の会話を追えます。 「コミットしました」「PR を上げました」「マージしてデプロイします」といった言葉が、作業がどこまで来たのかを知らせる合図として聞こえてきます。
- 「まだ本番にはありません」を理解できます。 「その機能は別のブランチで作業中なので、まだ合わさっていません」という言葉は、作ってはいるものの、メインブランチにマージもデプロイもされていないという意味です。
- バージョン管理は開発だけのものではありません。 誰がいつ何を変えたのかを残して戻すという発想は、デザインファイルや文書作業にもそのまま役立ちます。
シリーズを終えて #
五編にわたって、非開発者が知っておくとよい IT 常識を見てきました。
- #1 で、ウェブサイトがフロントエンド、バックエンド、データベースからできていることを見ました。
- #2 で、それらの層が API という約束で会話することを見ました。
- #3 で、バックエンドがサーバーとクラウドの上で動き、デプロイでユーザーに公開されることを見ました。
- #4 で、問題が起きるとホットフィックスとロールバックで対応することを見ました。
- #5 で、そのすべての変更が Git で記録され、管理されることを見ました。
これらの単語を自分で直接扱う機会はなくても、意味を知っているというだけで、開発者との会話がぐっと明瞭になります。会議で交わされる言葉が聞き取れ、スケジュールがなぜそう組まれるのかが納得でき、障害が起きたときも状況を落ち着いて読めます。このシリーズが、開発者と一緒に働くすべての方にとって、小さな地図になればと思います。