Git — 分散バージョン管理の事実上の標準

Gitは2005年、Linuxカーネルの開発者リーナス・トーバルズがそれまで使っていたBitKeeperの利用条件が変わったことを受けて、自ら2週間で書き上げた分散バージョン管理システムです。現在ではプロのソフトウェア開発でほぼ100%採用される事実上の標準ツールであり、「Gitが使えない」とエンジニアの仕事は始まらないと言っても過言ではありません。本記事ではGitの基本概念、SubversionなどとのVCS世代差、現場で頻出する操作の整理を行います。

この記事の目次

1. Gitの中核概念
2. 分散型と集中型の違い
3. 毎日使う基本コマンドの流れ
4. Gitと混同しやすい用語
5. まとめ

Gitの中核概念

Gitの世界はおおまかに「コミット」「ブランチ」「リモート」の三つで成り立っています。コミットは変更のスナップショット（差分ではなく、その時点のツリー全体のハッシュ）で、親コミットへの参照を持つことで履歴が連鎖します。

ブランチは特定のコミットに付けたしおりで、その先にどんどんコミットを積んでいけます。Subversionのようにブランチを作るたびにディレクトリをコピーするモデルとは違い、Gitのブランチは数バイトのポインタを動かすだけ。これがGitで「気軽にブランチを切る」文化を生んだ最大の技術的理由です。

分散型と集中型の違い

GitはSubversion（SVN）など旧世代の集中型VCSと違い、全開発者が完全な履歴を手元に複製します。通勤電車の中でブランチを作って何度コミットしても、サーバ通信は一切発生しません。オンラインに戻ってから push すれば履歴がリモートに反映されます。

この「分散型」という性質によって、GitHub・GitLab・Bitbucketのような公開リモートサービスを誰でも自由に建てられるという文化が育ちました。オープンソースの爆発的な普及は、Gitの分散モデルがあってこそ実現したと言えます。

毎日使う基本コマンドの流れ

現場で毎日使うGit操作は、おおまかに「クローン → ブランチを切る → 編集してコミット → プッシュしてPR」という流れです。個人の作業ブランチで自由に試行錯誤し、レビューを経てメインブランチへ統合するのが現代の開発スタイル。GitHub Flow / Git Flow など、組織ごとに細部の運用ルールが整備されています。

つまずきやすいのは rebase / merge の選択、コンフリクト解消、間違えてpushした後の取り消しといった応用操作です。「force-pushは共有ブランチでは絶対にしない」など、Git特有のお作法を早めに覚えると事故が減ります。

Gitと混同しやすい用語

「Git」と「GitHub」を同じものと誤解しているケースは初心者に限らず散見されます。GitはローカルPCで動くソフトウェアそのもの、GitHubはそのリモート置き場を提供する商用サービス、と覚えてください。GitHubが落ちてもローカルのGitリポジトリは無事ですし、別のホスティング（GitLab、社内サーバなど）に切り替えるのも難しくありません。

GitはCLI（コマンドライン）が本流ですが、VS Code・JetBrains IDE・SourceTreeなどGUIクライアントも多数あります。好みのものを使えばよいですが、コンフリクト解消や複雑な操作はCLIで叩けるようにしておくと、トラブル時の選択肢が広がります。

まとめ

Gitは2005年に生まれた比較的新しいツールでありながら、20年でソフトウェア開発の前提をすっかり書き換えました。「履歴を恐れず気軽に試す」「分散して並行作業する」という価値観そのものを浸透させた点で、単なるツールを超えた文化的インパクトを持っています。

※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。