Gitとは何か: 開発者にとっての役割と基礎

Git はバージョン管理システム

Gitは、プロジェクトのファイルの変更履歴を記録するプログラムです。コードの状態を記録するたびに、作成者、日時、説明とともにスナップショット（コミット）が保存されます。どのスナップショットにも戻れ、現在の状態と比較でき、特定の行を誰がなぜ変更したかを調べられます。

「project_v2」「project_final」「project_final_REALLY_FINAL」のようなフォルダを作ったことがあれば、手作業でバージョン管理をしていたことになります。Gitは同じことを自動的に、コンパクトに、そして何かを失う心配なしに行います。そのため、開発者の間で「Gitとは」と言えば、単なるプログラムではなく、コードエディタと同じくらい欠かせない基本ツールを指します。

フォルダのコピーやクラウドストレージとの違い

クラウドストレージは、ファイルの最新版と、せいぜい数個の自動バックアップを保存します。Gitは意味のある履歴を保存します。いつ記録するかは自分で決め、何を変えたかを書きます。さらに、どのストレージサービスにもできないことができます。

• 複数の開発ラインを同時に進め（ブランチ）、それらを統合する。
• バージョン間の行単位の差分を表示する（git diff）。
• 同じファイルに対する複数人の変更をまとめる。
• エラーが発生した最初のコミットを見つける（git bisect）。
• インターネットがなくても作業できる。履歴はすべてローカルにあるため。

Gitという名前の意味と読み方

Gitには公式の正式名称はありません。頭字語ではないからです。Linus Torvaldsは、自分らしいユーモアでこの名前を付けました。イギリスの俗語で git は「不快で頑固な人」を意味します。Torvalds自身は、すべてのプロジェクトを自分の名前にちなんで名付けていると冗談を言いました。直訳すると「のろま」「嫌なやつ」のような意味になります。

プロジェクトの最初の README で、作者は「Gitの略語」の冗談の候補をいくつか挙げています。例えば、すべてがうまくいっているときは「global information tracker」、壊れたときには悪態のような別の意味です。面接で「Gitの略語は何ですか」と聞かれたら、正解は「ありません。頭字語ではなく単語です」です。

読み方は「ギット」です。英語の発音に近い形で、最初の音を強く発音します。

Gitの誕生

2005年以前、Linuxカーネルの開発者はBitKeeperという独自のシステムを使っていました。コミュニティ向けの無償ライセンスが取り消されると、Torvaldsは数週間で独自のシステムを書き上げました。求められた要件は厳しいものでした。巨大なプロジェクトでの高速性、完全な分散型の作業、履歴の改ざんからの堅牢な保護、数千の並行ブランチを扱いやすいこと。

その後、現在もメンテナーを務めるJunio Hamanoがプロジェクトを引き継ぎました。今日のGitはGPLv2ライセンスのオープンソースシステムであり、GitHub、GitLab、Bitbucket、Gitea、そして企業向けの各種プラットフォームの基盤になっています。

Gitの仕組み

Gitを単なる魔法のようなコマンドの集まりではなく理解するために、3つの考え方を押さえておきましょう。ほとんどの動作はこれで説明できます。

1. 差分ではなくスナップショット

古いシステムの多くは、変更をファイルへの修正の集まりとして保存していました。Gitはスナップショットで考えます。各コミットは、その時点のプロジェクト全体の状態です。容量を節約するため、変更されていないファイルはコピーされず、コミットは既に保存されているオブジェクトを参照するだけです。リポジトリを圧縮（パック）するときには、似たオブジェクトがさらに圧縮されるため、大規模なプロジェクトの履歴でも容量はわずかです。

2. すべてがハッシュで識別される

Gitのすべてのオブジェクト（ファイルの内容であるblob、フォルダの構造であるtree、コミットであるcommit）は、その内容から計算された識別子を持ちます。従来はSHA-1（16進数40桁）が使われ、新しいバージョンではSHA-256のリポジトリも作成できます。古いコミットを気づかれずに変更することはできません。変更すると、そのハッシュと、その後のすべてのコミットのハッシュが変わるからです。

$ git log --oneline -3
a3f9c21 ログインフォームを追加
7b02e4d メールアドレスの検証を修正
1c8d5f0 最初のコミット

左側の短い文字列は、コミットの短縮ハッシュです。これを使ってどのバージョンにも移動できます。例: git show 7b02e4d。

3. ファイルの3つの状態

これはGitの基本中の基本で、ほぼすべての面接で聞かれます。プロジェクトのファイルは次の3つの領域のいずれかにあります。

インデックスは、Gitと多くの他のシステムを分ける特徴です。変更の一部だけをコミットにまとめられます。例えば、バグ修正と変数名の変更を別々のコミットにできます。それによって履歴が読みやすくなります。

分散型: なぜ全員がコピーを持つのか

Gitは分散型バージョン管理システム（DVCS）です。クローンすると、最新のファイルだけでなくプロジェクトの履歴全体を取得します。コミット、履歴の閲覧、ブランチの作成、比較といったほとんどの操作は、サーバーなしでローカルにすぐ実行されます。

このモデルでは、GitHubのようなサーバーは、チームが主要なものとして決めた別のコピーにすぎません。サーバーが利用できなくても作業は止まりません。コミットを続け、後で git push で送信できます。サーバーが完全に失われても、どのクローンからでも履歴を復元できます。

GitとGitHubは同じものではない

初心者がよく混同する点です。Gitは、あなたのコンピュータで動くプログラムです。GitHubは、Gitリポジトリを保存し、pull request、コードレビュー、タスク、CIなどのチーム向け機能を提供するWebサービスです。GitLabやBitbucketも同様のサービスです。

GitHubを使わずにGitだけを使うこともできます。例えば、個人のメモやローカルのプロジェクトです。一方、Gitを使わないGitHubは考えられません。GitHubはGitリポジトリを中心に作られているからです。

Gitの基本的な作業の流れ

日々の作業は次のような流れになります。以下のいくつかのコマンドで、開発者が毎日行う作業のほとんどをカバーできます。

# 現在のフォルダにリポジトリを作成
git init

# 何が変わったかを確認
git status

# ファイルをインデックスに追加
git add index.html style.css

# スナップショットを記録
git commit -m "トップページをマークアップ"

# 履歴を表示
git log --oneline

# ブランチを作成して移動
git switch -c feature/login

# ブランチを main に統合
git switch main
git merge feature/login

# 変更をサーバーに送信
git push origin main

git switch は、Git 2.23で git checkout の機能の一部を、より分かりやすく置き換えるものとして追加されました。古い手順書では git checkout -b feature/login を見かけるでしょう。意味は同じです。

git commit の内部で起きること

Gitはインデックスの内容を取り、各ファイルをblobとして保存し、フォルダごとにtreeオブジェクトを作り、commitオブジェクトを作成します。コミットには、treeへの参照、親コミットへの参照（マージの後は2つ）、作成者、コミッター、メッセージが含まれます。その後、現在のブランチのポインタが新しいコミットへ移動します。Gitのブランチは、最後のコミットのハッシュが入ったファイルそのものなので、ブランチは数ミリ秒で作成できます。

開発者にとってのGitの実用的なメリット

失敗を恐れずに試せる

どんな変更も元に戻せます。コードを壊したら、git restore ファイル で最後に記録したバージョンに戻せます。すでに履歴にある失敗したコミットは、git revert で逆向きのコミットを作れば、共有履歴を書き換えずに打ち消せます。巻き戻しに数秒しかかからないので、思い切って試せるようになります。

混乱のないチーム開発

各開発者は自分のブランチで作業し、他の人の邪魔をしません。タスクが完了すると、レビューを経て main に統合されます。2人が同じ箇所を変更していた場合、Gitは競合を表示し、意図的に解決させます。他人の作業を黙って上書きすることはありません。

文書としての履歴

良いコミットメッセージは、「なぜコードがこうなっているのか」に答えてくれます。git blame ファイル は、各行を誰がどのコミットで最後に変更したかを表示し、git log -p ファイル はファイルの変化の全体を表示します。1年後の調査で何時間も節約できます。

雇用者が求めるスキル

Gitの知識は、開発者、テスター、DevOpsエンジニア、データアナリストの求人のほぼすべてに書かれています。面接で確認されるのは、丸暗記したコマンドではなく理解です。mergeとrebaseの違い、インデックスとは何か、コミットをどう取り消すか、コンフリクトをどう解決するか。整理されたコミット履歴のあるGitHubのプロフィールは、ポートフォリオとしても機能します。

Gitが役立つ他の職種

Gitは、テキストファイルがあり履歴が重要な場面ならどこでも役立ちます。テクニカルライターのドキュメント（Markdown）、フロントエンドのマークアップ、アナリストのSQLスクリプトやノートブック、管理者のサーバー設定やインフラのコード（Infrastructure as Code）などです。動画、PSD、データセットのような大きなバイナリファイルには、Gitがテキスト向けに最適化されているため、Git LFS という拡張を使います。

Pro Git: 最高のGit書籍

さらに深く学びたい場合は、Scott ChaconとBen Straubによる「Pro Git」から始めましょう。無料で、オープンライセンスのもとで公開されており、公式サイト git-scm.com の Book セクションで読めます。日本語版もあります。「Pro Git」は、基礎から内部構造までを網羅した完全な教科書です。

効果的な読み方は次のとおりです。

• 第1〜3章（はじめに、基本、ブランチ）は必須の最低限です。ターミナルでコマンドを繰り返し試してください。
• リモートリポジトリとGitHubの章は、チームで作業を始めるときに読んでください。
• 「Git の内部」の章は、オブジェクトと参照が実際にどう動くのかを本当に理解したいときに読んでください。

もう1つの公式な情報源は、組み込みのヘルプです。git help commit や git commit --help で、そのコマンドの完全なドキュメントが開きます。git commit -h はオプションの簡単な一覧を表示します。

初心者がよく抱く誤解

• 「Gitはファイルを自動で保存する」。 いいえ。コミットするまで、変更は作業ディレクトリにしか存在しません。
• 「コミットはすぐにGitHubに反映される」。 コミットはローカルだけのものです。サーバーには git push の後で初めて送られます。
• 「git add は新しいファイル用のもの」。 git add は、追跡済みのファイルの変更もインデックスに追加します。
• 「履歴から消したものは戻せない」。 ほとんどの場合は戻せます。git reflog はポインタの移動を記録しており、「失われた」コミットもハッシュで見つけられます。
• 「ブランチはプロジェクトのコピーだ」。 ブランチは軽量なポインタであり、ファイルの複製ではありません。

学習の始め方

1. Gitをインストールし、バージョンを確認します: git --version。
2. 名前とメールアドレスを設定します: git config --global user.name と user.email。
3. 練習用のリポジトリを作成し、5〜10回コミットして、git log と git diff を見てみましょう。
4. ブランチで作業します。作成して統合し、わざとコンフリクトを起こして解決します。
5. GitHubのアカウントを作成してリポジトリを送信し、最初のpull requestを作成します。

この順番で進めると、リファレンスを順番に読むよりも早く上達します。各コマンドがリポジトリの状態をどう変えるかを、すぐに目で確認できるからです。

まとめ

Gitは分散型のバージョン管理システムです。プロジェクトの履歴をスナップショットとして保存し、ハッシュで保護し、チームがブランチで並行して作業できるようにします。名前に正式な意味はありませんが、「Gitとは」と聞かれたら、それは開発者にとって欠かせない基本ツールのことです。add、commit、pushの流れを身につけ、ファイルの3つの領域とブランチを理解してから、Pro Gitで学びを深めてください。最初のコミットからpull requestまでの全体を、Gitコースで段階的に実践できます。