「Git」という名前は、エンジニアなら誰でも一度は耳にしたことがあるはずです。
求人票にも当たり前のように書いてあるし、先輩からも「とりあえずGit使うから」と言われる。
でも、いざ「Gitって何？」と聞かれると、うまく説明できない——そんな人は少なくありません。
この記事では、
- そもそもなぜバージョン管理が必要なのかという歴史の話
- Gitが技術的にどういう仕組みで動いているのか
- 今日から使えるGitの基本コマンド
の3つを、順番に理解できるようにまとめました。
「なんとなく使う」から「理解して使う」へ。
読み終わる頃には、Gitという道具の見え方が変わっているはずです。
目次
- はじめに
- バージョン管理の歴史 〜Gitはなぜ生まれたのか〜
- Gitの技術的な仕組み 〜なぜGitは速くて壊れにくいのか〜
- Gitの基本的な使い方 〜実際に手を動かしてみる〜
- まとめ 〜「なんとなく」から「理解して使う」へ〜
1. はじめに
Gitって名前は聞くけど、実際なにをしてるツールなの？
一言でいうと、Gitは「ファイルの変更履歴を記録し、いつでも過去に戻ったり、複数人の変更を合流させたりできるツール」です。
たとえば、こんな経験はありませんか？
- ファイルを編集していたら、昨日の状態に戻したくなった
- 複数人で同じファイルを編集していて、誰がいつ何を変えたか分からなくなった
- 「とりあえずバックアップ」で、
report_final.docx
report_final2.docx
report_final_本当の最終.docx・・・
が量産される
Gitは、こうした問題を根本的に解決するために作られた仕組みです。
そして単なる「バックアップツール」ではなく、なぜそのような設計になったのかという歴史的な背景を知ると、Gitの使い方そのものへの理解がぐっと深まります。
この記事を読むと分かること
結論から言うと、Gitは「変更履歴を、安全かつ効率的に、複数人で分散管理するための仕組み」です。
この一文の意味を、歴史・技術・実践の3つの角度から解き明かしていきます。
2. バージョン管理の歴史 〜Gitはなぜ生まれたのか〜
そもそも「バージョン管理」って何のためにあるの？
先ほどの report_final_本当の最終.docx 問題を思い出してください。
これは個人の作業でも起きますが、何十人、何百人のエンジニアが同じソースコードを同時に編集するソフトウェア開発の現場では、さらに深刻な問題になります。
「誰が」「いつ」「どのファイルを」「なぜ変更したのか」を記録し、必要なら過去のどの時点にも戻れるようにする仕組み。
これがバージョン管理システム(VCS: Version Control System)です。
図1:バージョン管理システムは、ローカル型 → 集中型 → 分散型の順に進化してきた
第一世代:ファイルを手でコピーしていた時代(ローカル型)
初期のバージョン管理は、RCS(Revision Control System)やSCCS(Source Code Control System)のような、1つのコンピューター内で差分を記録する仕組みでした。
自分のPCの中だけで「変更前」と「変更後」を管理するもので、他の人と共同で使うことは想定されていませんでした。
第二世代:みんなで共有する集中型管理(CVS・Subversion)
次に登場したのが、CVSやSubversion(SVN)といった「集中型」のバージョン管理システムです。
中央に1台のサーバーを置き、全員がそこにアクセスして変更を記録する仕組みで、1980年代から長く使われてきました。
この仕組みにはメリットもありましたが、致命的な弱点がありました。
中央サーバーが落ちたら、誰も履歴にアクセスできなくなるのです。
また、ネットワークにつながっていないと作業履歴すら見られない、という不便さもありました。
図2:集中型は中央サーバー依存、分散型は全員が完全な履歴のコピーを持つ
転換点:Linus Torvaldsが「わずか数日」でGitを作った話
Gitの誕生には、実は少し生々しい裏話があります。
Linuxカーネルの開発チームは、2002年からBitKeeperという商用の分散型バージョン管理システムを無償利用していました。
しかしこのライセンスには、「競合するツールの開発に関わってはいけない」といった制約があり、コミュニティ内では以前から議論の的になっていました。BitKeeperのメタデータを確認する権限を持たない開発者は、過去のバージョンと比較することすらできず、多くのカーネル開発者にとって大きな不便になっていたのです。
2005年、この無償ライセンスが打ち切られる事態が起きます。BitKeeperの権利者だったLarry McVoyが、開発者のAndrew TridgellはBitKeeperの通信プロトコルをリバースエンジニアリングしたと主張したことが、この打ち切りの引き金になりました。
中心的な開発者であるLinus Torvaldsは、既存のオープンソースのバージョン管理システム(CVSやSubversion)では、Linuxカーネル開発に必要な性能要件を満たせないと判断していました。当時のカーネル開発では、パッチの適用を3秒以内に処理でき、なおかつ一度に250件ものパッチを同時に扱えるだけの性能が求められていたためです。
そこでTorvaldsは自ら新しいツールの開発に着手します。
開発は2005年4月3日に始まり、4月6日に公表、翌日には早くもそのツール自身で自分自身のソースコードを管理できるまでになったといいます。
最初のコミットの時点で、すでにそのコミット自体をGit自身で行えるくらいには実装が進んでいたそうです。
まさに「作りながら使う」というスピード感です。
その後、Torvaldsは開発の主導権をJunio Hamanoに引き継ぎ、2005年12月21日にGit 1.0.0が正式リリースされました。
参考:git-scm.com「A Short History of Git」
ちなみに「Git」という名前の由来について、Torvalds自身は自虐的なジョークとして「イギリスのスラングで“嫌なやつ”という意味で、自分のプロジェクトには自分の名前をつける主義だから」と語っています(出典:Wikipedia「Git」)。
第三世代:分散型という発想の転換
こうして生まれたGitは、それまでの集中型とはまったく異なる設計思想を持っていました。
全員が、中央サーバーと同じように「完全な履歴のコピー」を自分のPCに持つという、分散型のアーキテクチャです。
この設計により、
図1:バージョン管理システムは、ローカル型 → 集中型 → 分散型の順に進化してきた
- ネットワークがなくてもコミットや履歴確認ができる
- 特定のサーバーがダウンしても、誰かの手元に完全な履歴が残る
- ブランチの作成やマージが圧倒的に軽量になる
といったメリットが生まれました。
同時期に生まれたMercurialも同様の分散型思想を持つツールですが、最終的にGitが業界標準として定着していきます。
3. Gitの技術的な仕組み 〜なぜGitは速くて壊れにくいのか〜
Gitは「差分」を記録していない?! スナップショットという考え方
多くの人が誤解しがちなポイントですが、Gitは各コミットにおいて「前のバージョンとの差分」だけを記録しているわけではありません。
コミットのたびに、その時点の全ファイルの状態(スナップショット)を丸ごと記録しています。
ただし、変更されていないファイルは新しく複製せず、以前のスナップショットへの参照だけを持つため、効率的に保存できる仕組みになっています。
コミットって実は何をしているのか
Gitの内部では、大きく3種類の「オブジェクト」でデータを表現しています。
| オブジェクト | 役割 |
|---|---|
| blob | ファイルの中身そのもの |
| tree | フォルダ構造(どのblob・treeがどこにあるか) |
| commit | ある時点のtreeへのポインタ + 作者・日時・親コミットの情報 |
つまり1回のコミットは、「このフォルダ構造(tree)を、この情報(作者・日時・メッセージ)とともに記録し、1つ前のコミットにつなげる」という処理をしているわけです。
ブランチが一瞬で作れる理由(ポインタの正体)
集中型のバージョン管理システムでは、ブランチの作成が重い処理になりがちでした。
しかしGitでは、ブランチは「特定のコミットを指す、ただのポインタ(ラベル)」にすぎません。
図3:ブランチの実体は「どのコミットを指しているか」という軽量なポインタ
新しいブランチを作るというのは、「今いるコミットに、新しい名前のラベルを貼る」だけの操作です。
だからこそGitのブランチ作成は一瞬で終わり、気軽に何本でも作業ブランチを切ることができます。
SHA-1ハッシュとは — データの「指紋」で改ざんを防ぐ仕組み
Gitのすべてのオブジェクト(blob・tree・commit)には、その内容から計算されたSHA-1ハッシュ値という40文字の識別子が割り振られています。
これは内容が1バイトでも変わればまったく違う値になる、いわば「データの指紋」です。
このハッシュは本来、悪意のある改ざんよりも偶発的なデータ破損を検知する目的が大きかったと、Torvalds自身が説明しています。
とはいえ結果的に、履歴の整合性を保証する重要な仕組みとして機能しています。
なお2017年に脆弱性が実証されたことを受け、Git内部では衝突耐性を強化したSHA-1の変種が採用されています(出典:Wikipedia「Git」)。
こっそり.gitフォルダの中を覗いてみよう
Gitで管理しているフォルダには、必ず .git という隠しフォルダが存在します。
ここにこそ、これまで説明してきたオブジェクトやブランチの情報がすべて詰まっています。
cd your-project
ls -la .gitobjects フォルダの中に、先ほどのblob・tree・commitがハッシュ値をファイル名として保存されているのが分かります。
普段は直接触る必要はありませんが、「Gitの正体はこのフォルダの中身である」と知っておくと、トラブル時の理解が格段に速くなります。
ワーキングディレクトリ・ステージング・リポジトリの3つの領域
Gitを使ううえで最初につまずきやすいのが、この3つの領域の違いです。
- ワーキングディレクトリ:今あなたが実際に編集しているファイル
- ステージングエリア(インデックス):次のコミットに含める変更を仮置きする場所
- リポジトリ:コミットとして正式に記録された履歴
「編集する → git add でステージングに載せる → git commit でリポジトリに記録する」という3段階の流れが、次章の基本コマンドとつながってきます。
4. Gitの基本的な使い方 〜実際に手を動かしてみる〜
準備:Gitのインストールと初期設定
公式サイトからGitをインストールしたら、最初に名前とメールアドレスを設定します。
git config --global user.name "Your Name"
git config --global user.email "you@example.com"インストール方法の詳細は公式ドキュメントも参考にしてください:Git公式サイト
リポジトリを作る・複製する
新しくプロジェクトを始めるとき:
git initすでにあるプロジェクト(GitHubなど)を手元にコピーするとき:
git clone https://github.com/ユーザー名/リポジトリ名.git変更を記録する3ステップ
前章で説明した「ワーキングディレクトリ → ステージング → リポジトリ」の流れを、実際のコマンドにするとこうなります。
git add ファイル名 # 変更をステージングに載せる
git commit -m "コミットメッセージ" # リポジトリに記録する
git push # リモート(GitHubなど)に反映するgit add . とすれば、変更したファイルをまとめてステージングできます。
コミットメッセージは「何を」「なぜ」変更したのかが後から分かるように書くのがコツです。
過去に戻ってみる
これまでのコミット履歴を確認するには:
git log特定の過去のコミット時点のファイルを確認したいときは git checkout や git switch を使います。
ブランチを切って作業する
新しいブランチを作って移動する:
git checkout -b new-feature現在のブランチを確認する:
git branch「試しに実装してみて、うまくいかなければ捨てる」ができるのが、ブランチを使う最大のメリットです。
前章で説明した通り、Gitではブランチ作成のコストがほぼゼロなので、遠慮なく作業単位でブランチを切るのが基本スタイルになります。
変更を合流させる
作業が終わったブランチをメインのブランチに合流させるには:
git checkout main
git merge new-featureコンフリクトが起きたらどうする?
複数人が同じ箇所を編集していると、マージ時に「コンフリクト(競合)」が発生することがあります。
これはGitが「どちらの変更を採用すべきか自動判断できない」状態を知らせてくれているだけで、決して壊れたわけではありません。
該当ファイルを開くと、次のような記号でコンフリクト箇所が示されます。
<<<<<<< HEAD
自分の変更内容
=======
相手の変更内容
>>>>>>> new-feature不要な行を削除し、正しい内容に手動で書き換えたあとにコミットすれば解決です。
最初は戸惑うポイントですが、慣れれば数分で対応できるようになります。
5. まとめ 〜「なんとなく」から「理解して使う」へ〜
ここまで、バージョン管理の歴史からGitの内部構造、そして日常的な使い方までを見てきました。
- 集中型の限界から分散型という発想が生まれたこと
- Gitがスナップショットとハッシュ値によって速く、壊れにくい仕組みを実現していること
add→commit→pushという基本フローと、ブランチの活用方法
これらを知っているだけで、エラーメッセージを見たときの理解度や、チーム開発でのコミュニケーションの質が大きく変わってきます。
次に学ぶといいこと
- GitHubの使い方(Pull Request、Issue、レビューの流れ)
git rebaseやgit cherry-pickといった応用コマンド- チームごとのブランチ運用ルール(Git Flow、GitHub Flowなど)
まずは今日紹介した基本コマンドを、実際に小さなプロジェクトで動かしてみてください。
「歴史を知って、仕組みを理解して、手を動かす」——この順番が、Gitを本当の意味で使いこなす一番の近道です。