Git
コードの変更履歴を管理する分散型バージョン管理システム。現代開発の共通基盤。
概要
Gitは、ソースコードの変更履歴を記録・管理するバージョン管理システムです。「いつ・誰が・何を・なぜ変えたか」をコミットという単位ですべて記録し、任意の時点の状態に戻したり、変更同士を比較したりできます。手作業の「ファイル名に日付を付けて複製する」管理とは違い、履歴そのものがデータ構造として扱えるのが本質です。
もう1つの柱がブランチです。履歴を枝分かれさせて複数の作業を並行に進め、あとで合流（マージ）できます。GitHubに代表される共有プラットフォームと組み合わせることで、プルリクエストによるコードレビュー、CI/CDによる自動検証・自動デプロイといった、現代の開発プロセス全体の土台になっています。今日ソフトウェア開発の職に就くなら、言語より先に触ることになる道具かもしれません。
なぜ生まれたか
バージョン管理システム自体はGit以前からあり、2000年代前半はSubversion（SVN）などの「集中型」が主流でした。集中型では履歴を持つのは中央サーバだけで、コミットや履歴の閲覧のたびにサーバへの接続が必要です。オフラインでは作業しづらく、ブランチ作成も重い操作だったため、「気軽に枝分かれして実験する」文化は育ちにくいものでした。
Gitが生まれた直接のきっかけはLinuxカーネル開発です。世界中の数千人が並行に開発する巨大プロジェクトで使っていた商用ツールBitKeeperが使えなくなり、2005年、Linus Torvaldsが自ら代替を書きました。要件は「完全に分散して動くこと」「数万ファイルでも高速なこと」「履歴の改竄が検出できること」。各開発者が履歴の完全な複製を手元に持つ分散型の設計により、コミットもブランチもローカルで一瞬で完了するようになり、「小さくコミットし、気軽にブランチを切る」現代のスタイルが可能になりました。
詳細
3つのエリアとコミットの流れ
Gitを使う日常は、「作業ディレクトリ→ステージングエリア→リポジトリ」という3つのエリアの往復です。ファイルを編集し、コミットに含めたい変更だけを git add でステージングエリアに載せ、git commit でメッセージ付きの履歴として確定します。ステージングという中間段階があるおかげで、「直した内容のうち意味のまとまりごとに分けてコミットする」ことができます。
内部的には、コミットは「その時点のスナップショット＋親コミットへの参照＋作者・メッセージ」の塊で、内容のハッシュ化（SHA-1/SHA-256）で識別されます。ハッシュが内容から計算されるため、過去の履歴を書き換えれば必ず検出できます。ブランチの実体は「特定のコミットを指すただのポインタ」にすぎず、だからこそ作成も切り替えも一瞬です。
ブランチ、マージ、コンフリクト
チーム開発の基本形は「main（本流）を安定に保ち、作業はブランチを切って行い、完成したらマージで合流させる」というものです。GitHub上ではこの合流の前にプルリクエスト（PR）を挟み、差分をレビューし、CI/CDでテストを自動実行してからマージするのが標準的な流れです。履歴が枝分かれして再び合流する様子は、コミットのつながりとして図にすると分かりやすくなります。
合流時に同じ箇所を双方が変更していると「コンフリクト（衝突）」が起き、どちらを採用するか人間が判断してマージを完成させます。コンフリクトは異常事態ではなく並行開発の必然ですが、ブランチを長生きさせるほど差分が膨らんで解消が苦しくなります。「ブランチは小さく短命に、こまめに本流を取り込む」が実務の基本姿勢です。合流の手段にはマージのほかにリベース（自分のコミットを本流の先頭に付け替えて履歴を一直線にする方法）もあり、履歴の読みやすさを取るか操作の安全さを取るかのトレードオフとして使い分けます。
分散型であることの意味
Gitではクローンした全員が全履歴のコピーを持ちます。コミット・ブランチ・履歴閲覧・差分比較はすべてローカルで完結し、ネットワークが必要なのは push/pull で他のリポジトリと同期するときだけです。GitHubやGitLabは技術的には「みんなが同期先として合意した、ただのリモートリポジトリ」であり、Gitの仕組み上の中心ではありません。この分散性は事実上のバックアップにもなっており、中央サーバが消えても誰かのクローンから完全に復元できます。
実務での使いどころと落とし穴
Gitの価値は「安心して変更できること」に尽きます。いつでも戻れるからこそ大胆にリファクタリングでき、git log や git blame で「このコードはなぜこうなっているのか」を過去のコミットメッセージから辿れます。だからこそコミットは「意味のある単位で小さく、メッセージには何をなぜ変えたかを書く」ことが将来の自分とチームへの投資になります。
落とし穴の代表は、push済みの履歴を書き換えて（rebase や force push）チームメイトの履歴と食い違わせてしまうこと、そしてパスワードやAPIキーなどの秘密情報をコミットしてしまうことです。Gitは履歴を消さない設計なので、一度コミットした秘密情報は「削除コミット」を積んでも履歴に残り続けます。push してしまったら履歴の書き換えではなく、鍵そのものの無効化・再発行で対処するのが原則です。