Gitの仕組み

Gitはコードの「セーブ＆ロード」ができるツールです。

もしGitがなかったら、コードの管理はこうなります。

Gitは2005年に、Linux（リナックス）というOSを開発したリーナス・トーバルズが作りました。Linuxは世界中の何百人もの開発者が同時にコードを変更するプロジェクトです。その膨大な変更を安全に管理するために生まれたのがGitでした。つまりGitは最初から、大規模なチーム開発のために設計されたツールなのです。

Gitを使うとき、ファイルは3つの場所を行き来します。この3つの関係がわかれば、Gitの仕組みの大半は理解できたと言っても過言ではありません。

わかりやすいように、「手紙を書いて送る」プロセスにたとえてみましょう。

Gitの日常的な作業は、たった4つのステップの繰り返しです。開発者が毎日何十回と繰り返すこの流れを、順番に見ていきましょう。

では実際に、ターミナル（コマンドを入力する黒い画面）で打つコマンドを見てみましょう。たったこれだけのコマンドで、変更が記録されてクラウドに送信されます。

# 1. ファイルを編集する（普通にコードを書く。Gitの操作は不要）

# 2. 変更したファイルをステージングに追加する
$ git add index.html

# 3. メッセージ付きで変更を記録する
$ git commit -m "ログインページのデザインを変更"

# 4. 記録をリモート（クラウド）に送信する
$ git push origin main

逆に、チームメンバーがクラウドに送った変更を自分のパソコンに取り込むときは、git pull を使います。

# リモートの最新状態を自分のパソコンに取り込む
$ git pull origin main

# 変更履歴を確認する（誰が何をしたか一覧で見える）
$ git log --oneline
a1b2c3d ログインページのデザインを変更
e4f5g6h ユーザー登録機能を追加
i7j8k9l データベース接続設定を修正

Gitの最も強力な機能のひとつがブランチ（Branch = 枝）です。ブランチとは、開発のメインラインから「枝分かれ」して、独立した作業空間を作る仕組みのことです。

たとえ話で考えてみましょう。あなたは小説を書いています。本筋はほぼ完成していますが、「この登場人物を追加したらどうなるだろう？」と実験したい。でも本筋を直接書き換えて失敗したら大変です。そこで原稿をまるごとコピーして、コピーの方で思い切り実験する。うまくいったら本筋に反映する。ダメだったらコピーを捨てるだけ。これがブランチの考え方です。

ここでのポイントは、featureブランチでの作業中も、mainブランチには一切影響がないということです。小説のたとえで言えば、コピー原稿をどんなに書き換えても、金庫にしまった本筋の原稿は無傷のまま。だからこそ安心して大胆な実験ができるのです。

# 新しいブランチを作って、そこに切り替える
$ git switch -c feature-login

# ブランチ上で自由にコードを書く（mainには影響しない）
$ git add login.html
$ git commit -m "ログイン機能を実装"

# mainブランチに戻る
$ git switch main

# featureブランチの変更をmainに統合する
$ git merge feature-login

「Git」と「GitHub（ギットハブ）」は名前が似ていますが、まったく別のものです。混同している人がとても多いので、ここで明確に区別しておきましょう。ひとことで言えば、GitはWordのような「ツール」、GitHubはGoogle Driveのような「サービス」です。

Gitについて学び始めると、多くの人が同じところでつまずきます。ここでは、よくある3つの誤解を取り上げて、正しい理解に修正します。