結論： Git（ギット）とは、プログラムのソースコードなどの変更履歴を記録・追跡するための「分散型バージョン管理システム」です。
Web開発の現場において、Gitを使わないプロジェクトはほぼ存在しません。これは単なるツールではなく、エンジニアがチームで安全かつ効率的に開発を進めるための「共通言語」であり「インフラ」です。
H2: なぜ「ファイル名での管理」は破綻するのか
プログラミング初心者が最初に直面する、そして最も避けるべき管理手法が「ファイル名によるバックアップ」です。
手動管理の限界とリスク
あなたはこれまで、重要な書類やレポートを作成する際、こんなファイルを作ったことはないでしょうか？
- report.docx
- report_v2.docx
- report_final.docx
- report_final_submission.docx
- report_final_hontou_ni_final.docx
Mikotoうっ、これ私よくやります…。不安だから「最新」とか「修正版」とかつけちゃうんですよね。
Yachi個人作業ならそれでなんとかなることもありますが、チーム開発だとそれが「地獄」の入り口になります。
ソフトウェア開発は「数千個のファイル」を「複数人」で同時に編集します。もしチーム開発でこれをやると、以下のような問題が発生します。
- どれが最新かわからない: 「final」の後に「v2」ができたりして、正解が消失します。
- 上書き事故: AさんとBさんが同時に
index.htmlを編集し、後から保存した方が相手の作業を消してしまいます。 - 過去に戻れない: 「3日前の状態に戻したい」と思った時、どのファイルがその時点のものか特定できません。
Gitによる解決策：ファイル名は変えない
Gitを使うと、ファイル名は常に index.html のままでOKです。その代わり、Gitが裏側で「いつ、誰が、どのファイルの、どこを変更したか」という情報をデータベースとして積み上げていきます。
ユーザーからは常に最新の状態が見えていますが、コマンド一つで「3日前の14時の状態」や「特定の機能を追加する前の状態」へ、ファイルの中身を瞬間的に巻き戻すことができます。
「分散型」であることの強み
バージョン管理システムには、古い「集中型（Subversionなど）」と、現在の主流である「分散型（Git）」があります。
Gitの最大の特徴は、全員がリポジトリ（変更履歴のデータベース）の完全なコピーを手元に持っている点です。
- オフライン作業が可能: 中央サーバーに繋がっていなくても、手元のPCだけで履歴の記録や閲覧ができます。飛行機の中でも開発が進められます。
- リスク分散: もし中央サーバー（GitHubなど）がデータ消失しても、チームメンバーの誰かのPCにデータが残っていれば、そこから完全に復旧できます。
H2: Gitの仕組み：「写真撮影」で理解する3つのエリア
Gitの操作を理解する上で、最大のハードルとなるのが「なぜコマンドを2回打たないと記録されないのか？」という点です。これを理解するために、「写真スタジオでの撮影プロセス」に例えて解説します。
Gitには、データが存在する3つのエリアがあります。
1. ワーキングツリー（作業ディレクトリ）
＝ スタジオのセット
あなたが実際にエディタでコードを書いたり、ファイルを修正したりしている場所です。
スタジオのセットでは、被写体（ファイル）を動かしたり、小道具を変えたり自由に作業できます。この時点では、まだカメラに記録されていません。いくら変更しても、Gitの歴史には残りません。
2. ステージングエリア（インデックス）
＝ カメラのファインダー
「今回の記録に含めたい変更」を選んで、カメラのファインダー（フレーム）に収める場所です。
作業したファイルが10個あっても、記録したいのはそのうちの2個だけかもしれません。この「記録対象を選ぶ」操作が git add です。まだシャッターは切っていません。構図を決めた段階です。
3. ローカルリポジトリ
＝ 現像済みのアルバム
シャッターを切って、フィルムに焼き付ける場所です。
ここで初めて、変更内容が確定した「歴史」として記録されます。この操作が git commit です。一度コミットされたデータは、後からいつでも閲覧したり、復元したりできます。
なぜ「add」と「commit」に分かれているのか？
Mikoto正直、ここが一番意味わからないです。いきなりコミットすれば良くないですか？二度手間な気がして…。
Yachiいい質問ですね。でも実は、この「ワンクッション」があることが、Gitの最大の武器なんです。
例えば、開発中に「機能Aの実装」と「誤字の修正」と「テスト用の設定変更」を同時に行ったとします。これらをまとめて1回で記録すると、後から履歴を見返した時に「何の変更なのか」が分かりにくくなります。
Gitでは、まず「機能A」だけをステージングしてコミット、次に「誤字修正」だけをステージングしてコミット……というように、意味のある単位で履歴を分割して記録できます。そのための「仕分け場所」としてステージングエリアが存在します。
Yachi個人的には、コミットの粒度は「細かければ細かいほど良い」と考えています。あとからバグが見つかったとき、変更単位が小さいほど原因特定や切り戻しが楽になるからです。「作業の区切り」ではなく「意味の区切り」でコミットする癖をつけると、一気に上級者に近づけますよ。
4. リモートリポジトリ
＝ クラウド上の共有アルバム（Instagramなど）
ローカルリポジトリ（自分の手元のアルバム）に溜まった写真を、チームメンバーが見られるようにWeb上にアップロードする場所です。これがGitHubなどに相当します。
H2: 環境構築：Gitのインストールと初期設定
それでは、実際に手元のPCでGitを使えるようにしましょう。
インストール手順
Windowsの場合
公式サイト（git-scm.com）からインストーラーをダウンロードして実行します。
インストール中に多くのオプションが表示されますが、基本的には全て「Default（推奨）」のままで進めて問題ありません。
インストールが完了すると、「Git Bash」というツールが使えるようになります。これはWindows上でLinuxのようなコマンド操作を可能にするソフトです。PowerShellやコマンドプロンプトでもGitは動きますが、以下の理由からGit Bashの使用を強く推奨します。
YachiWindowsユーザーの方には、必ず「Git Bash」を使ってほしいです。Web開発の現場（サーバー操作など）ではLinuxコマンドが標準語なので、今のうちにGit Bashで慣れておくと、将来的な学習コストが劇的に下がります。
macOSの場合
Macには標準でGitがインストールされていることが多いですが、バージョンが古い場合があります。パッケージ管理ツール「Homebrew」を使って最新版を入れるのが一般的です。
ターミナルを開き、以下のコマンドを実行します。
brew install gitバージョン確認
ターミナル（WindowsならGit Bash）を開き、以下のコマンドを入力してバージョン番号が表示されれば成功です。
git --version
# 出力例: git version 2.43.0【必須】ユーザー情報の登録
Gitを使い始める前に、必ずやっておくべき設定があります。「誰が変更したか」を記録するためのユーザー名とメールアドレスの登録です。
注意: これを設定しないと、コミットしようとした瞬間にエラーや警告が出て先に進めなくなります。インストールしたら最初に実行してください。
git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"※ Your Nameには英数字の名前、メールアドレスはGitHubに登録するもの（または普段使うもの）を設定してください。
設定されたか確認するには以下を実行します。
git config --listH2: 【実践】基本のセーブ機能をマスターする
ここからは実際に手を動かして、ローカル環境でファイルの変更履歴を管理する流れを体験します。
今回はシナリオとして、「京都の旅行ガイドブック（テキストファイル）」を作成・編集する過程を管理してみましょう。
Mikotoいよいよ黒い画面ですね…ちょっと怖いです。
Yachi大丈夫です。「フォルダを作って」「ファイルを入れて」「セーブする」。やっていることは普段の作業と同じです。コマンドに慣れていきましょう。
1. リポジトリの作成（アルバムの用意）
まず、プロジェクト用のフォルダを作成し、Gitの管理下に置きます。
mkdir kyoto-guide
cd kyoto-guide
git initgit init を実行すると、フォルダ内に隠しフォルダ .git が生成されます。これがGitのデータベース（アルバムの台紙）です。これ以降、このフォルダ内の変更はGitによって監視されます。
2. ファイルの作成と状態確認
ガイドブックの原稿ファイルを作成します。
# ファイルを作成（中身は空でもOK、適当なテキストを入れる）
echo "Kyoto Sightseeing Guide" > spots.txt現在の状況を確認するために、最も頻繁に使うコマンド git status を実行します。
git statusすると、spots.txt が赤字で表示され、「Untracked files（追跡されていないファイル）」と警告されます。これは「スタジオに新しい被写体があるが、まだカメラを向けていない状態」です。
3. ステージング（ファインダーに収める）
このファイルを記録対象にするため、ステージングエリアに追加します。
git add spots.txt※ 変更された全ファイルを対象にする場合は git add . を使います。
もう一度 git status を確認すると、ファイル名が緑字に変わり、「Changes to be committed（コミット予定の変更）」と表示されます。これで撮影準備完了です。
4. コミット（シャッターを切る）
履歴として確定させます。コミット時には必ず「どのような変更をしたか」というメッセージを添える必要があります。
git commit -m "add title to guide"これで1枚目のスナップショットが記録されました。
Yachiコミットメッセージ（-m の中身）は、未来の自分やチームへの手紙です。「update」や「fix」といった適当な言葉ではなく、「何を追加したか」「なぜ修正したか」がわかるように具体的に書く習慣をつけましょう。
5. 履歴の確認
どのような歴史が刻まれたか確認します。
git log以下のような情報が表示されます。
- commitハッシュ: 履歴を特定するID（例:
a1b2c3d...） - Author: 編集者情報
- Date: 日時
- Message: “add title to guide”
この add → commit のサイクルが、Git操作の基本中の基本です。
H2: GitHub連携：データをクラウドへバックアップ
手元のPC（ローカル）だけで管理していても便利ですが、PCが壊れたらデータは消えますし、他人との共有もできません。そこで、Web上のホスティングサービス「GitHub」と連携します。
GitとGitHubの違い
Mikotoあの、基本的なこと聞いていいですか？GitとGitHubって何が違うんですか？名前が似てて混同しちゃって。
Yachiよくある疑問ですね。料理で例えるなら、Gitは「包丁やまな板（道具）」で、GitHubは「キッチンのある料理教室（共有スペース）」です。
- Git: バージョン管理を行うための「ツール」。手元のPCで動きます。
- GitHub: Gitのデータを保存・共有するための「Webサービス」。インターネット上にあります。
手順1: GitHubでリポジトリを作成
ブラウザでGitHubにログインし、右上の「+」ボタンから「New repository」を選択します。
Repository nameに kyoto-guide と入力し、「Create repository」をクリックします。
手順2: リモートの登録（宛先の設定）
作成後の画面に表示されるコマンドを使います。これは「手元のGitに、アップロード先のURLを教える」作業です。
# originという名前でURLを登録（URLは自分のものに置き換えてください）
git remote add origin https://github.com/YourName/kyoto-guide.git手順3: プッシュ（アップロード）
手元のコミット履歴をGitHubへ送信します。
git push -u origin main※ 初回のみ -u オプションを付けます。これは「次回から単に git push と打つだけで、自動的に origin の main に送るよ」という紐付け設定です。
ブラウザでGitHubのページをリロードすると、先ほど作った spots.txt が表示されているはずです。
補足：認証について
現在、セキュリティ強化のためパスワード認証は廃止されています。プッシュ時に認証を求められた場合、Personal Access Token (PAT) を発行してパスワード代わりに入力するか、SSH鍵設定を行う必要があります。
YachiWindowsを使っている場合、「Git Credential Manager」という補助ツールが自動で起動して、ブラウザでのログインボタンを押すだけで認証が完了するケースがほとんどです。難しく考えすぎず、まずは画面の指示に従ってみてください。
クローン（ダウンロード）
逆に、既にあるリポジトリ（他人のコードや、別のPCで作業する場合）を手元に持ってくるには clone を使います。
git clone https://github.com/YourName/kyoto-guide.gitこれでクラウド上のアルバムが丸ごと複製されます。
H2: 【実践】並行世界を作る「ブランチ」と「マージ」
チーム開発におけるGitの真骨頂が「ブランチ（Branch）」機能です。これは、メインの進行ラインに影響を与えずに、並行して別の作業を行うための仕組みです。
ブランチのイメージ
ガイドブックの編集で例えるなら、以下のようなイメージです。
- mainブランチ: 印刷所に入稿できる「完成版」の状態。
- featureブランチ: 「グルメ特集」の記事を書くための「コピーした下書き用紙」。
下書き用紙でいくら修正したり失敗したりしても、完成版（main）は無傷です。書き上がってチェックが済んだら、完成版に取り込みます。
Mikotoなるほど！コピーして作業するから、本番環境を壊す心配がないんですね。
Yachiその通りです。現場では、main ブランチに直接コミットすることはまずありません。必ず作業用ブランチを切って、そこでテストしてから統合するのが鉄則です。
1. ブランチの作成と移動
現在のブランチを確認します。
git branch
# * main新しい作業用ブランチ feature-food を作成し、そこへ移動します。
以前は checkout というコマンドが使われていましたが、現在はより直感的な switch が推奨されています。
# 作成して移動を同時に行うオプション -c (create)
git switch -c feature-foodネット上の古い記事では git checkout -b というコマンドが紹介されていることが多いですが、個人的には新しい git switch を使うことを推奨します。コマンド名が直感的で、初心者でも混乱しにくいからです。
2. 分岐先での作業
ここで新しいファイル food.txt を作り、コミットします。
echo "Yatsuhashi, Matcha" > food.txt
git add food.txt
git commit -m "add food list"この時点では、feature-food ブランチだけが進んでおり、main ブランチには food.txt は存在しません。
3. マージ（統合）
作業が完了したので、main に変更を取り込みます。
まず、取り込む側（main）に戻ります。
git switch mainそして、feature-food の内容を統合（マージ）します。
git merge feature-foodこれで main ブランチにも food.txt が反映されました。不要になったブランチは削除しても構いません。
H2: トラブルシューティング：競合（コンフリクト）の解決策
Gitを使っていると、必ず遭遇するのが「コンフリクト（競合）」です。これは、「同じファイルの同じ行を、別々の内容に書き換えてマージしようとした時」に発生します。
Gitは「どっちが正しいか自動では判断できないから、人間が決めてくれ」と言って処理を中断します。これはエラーというより、上書き事故を防ぐための安全装置です。
Mikotoコンフリクト…名前からして怖そう。これが出たら全部やり直しですか？
Yachiいえ、落ち着いて対処すれば数分で解決できます。「Gitが判断を仰いでいる」だけなので、人間がエディタで「こっちが正解」と教えてあげればOKです。
コンフリクトの発生例
ガイドブックの spots.txt の1行目について、
- Aさんは「Recommended: Kinkaku-ji」と書いてコミット。
- Bさんは「Recommended: Ginkaku-ji」と書いてコミット。
これをマージしようとすると、以下のエラーが出ます。CONFLICT (content): Merge conflict in spots.txt
解決手順
1. ファイルを開く
エディタで spots.txt を開くと、Gitが自動的に以下のような記号を挿入しています。
<<<<<<< HEAD
Recommended: Kinkaku-ji
=======
Recommended: Ginkaku-ji
>>>>>>> feature-B<<<<<<<から=======までが、現在の変更（自分）。=======から>>>>>>>までが、取り込もうとした変更（相手）。
2. 手動で修正する
この記号を含めて不要な部分を削除し、あるべき姿に書き直します。今回は両方残すことにしましょう。
Recommended: Kinkaku-ji and Ginkaku-ji記号は全て消して、普通のテキストに戻します。
3. 再コミット
修正が終わったら、通常通りコミットします。
git add spots.txt
git commit -m "fix conflict: merge both temples"これでコンフリクトは解消です。焦らずファイルの中身を見て修正すれば、何も怖いことはありません。
H2: 脱初心者への道標：現場で出会う用語集
最後に、実務に入ると頻繁に耳にする用語や機能を簡単に紹介します。これらを知っておくと、現場での会話がスムーズになります。
.gitignore（ギットイグノア）
Gitで管理したくないファイルを指定するリストです。
OSが勝手に作る設定ファイル（.DS_Store）や、パスワードが書かれた環境変数ファイル、ビルドで自動生成されるファイルなどを記述します。ここに書かれたファイルは git add . をしても無視されます。
Pull Request (プルリクエスト / PR)
GitHubなどの機能です。ブランチでの作業が終わった際、いきなりマージするのではなく、「マージしてもいいですか？」とチームメンバーにレビューを依頼する手続きです。
コードの品質を保つために、現場では「PRを出して、承認されたらマージ」というフローが一般的です。
Rebase（リベース）
マージの一種ですが、履歴を一本の直線に綺麗に整える手法です。
通常の merge は合流の記録（マージコミット）が残りますが、rebase は「枝分かれしなかったこと」にして履歴を繋ぎ直します。履歴が見やすくなりますが、使い方を誤ると共有リポジトリの整合性を壊すリスクがあるため、慣れるまでは注意が必要です。
Cherry-pick（チェリーピック）
他のブランチにあるコミットの中から、「特定のコミットひとつだけ」をつまみ食いして取り込む機能です。
「開発用ブランチの機能はまだ未完成だけど、そこで修正したバグ対応だけ先にメインに取り込みたい」といったケースで役立ちます。
まとめ
Gitは、最初は「黒い画面にコマンドを打つ」というだけで難しく感じるかもしれません。しかし、その本質は「失敗を恐れずに作業するための命綱」です。
- add と commit でこまめにセーブする。
- branch を切って、本番環境を守りながら実験する。
- push してクラウドにバックアップを取る。
このサイクルさえ守っていれば、どんなにコードを壊しても、いつでも元通りに復元できます。
Yachi最近はVS CodeなどのエディタでもGit操作はできますが、個人的には最初はコマンド操作（CUI）で学ぶことを強くおすすめします。「裏で何が起きているか」を理解していないと、ツールがエラーを吐いたときに手も足も出なくなるからです。
コマンドに慣れてから便利なGUIツールを使う。この順番が、エンジニアとしての基礎体力をつける最短ルートです。
まずは個人のメモ書きや学習用のコード管理からGitを導入し、コマンド操作に指を慣らすところから始めてみてください。
よくある質問 (FAQ)
- コマンド操作（黒い画面）は必須ですか？
-
必須ではありません。VS CodeなどのエディタにはGit機能が内蔵されていますし、SourceTreeやGitHub Desktopといった視覚的に操作できるツール（GUI）も優秀です。
ただし、エラーが発生した際のトラブルシューティングや、複雑な操作を行う際にはコマンドの知識が必要になる場面があります。「基本はGUI、困ったらコマンド」という使い分けでも十分実用的です。 - 間違ってコミットしてしまった場合、取り消せますか？
-
可能です。直前のコミットメッセージを修正したいだけなら
git commit --amendが使えます。
コミット自体を取り消して作業前に戻したい場合はgit resetなどのコマンドがありますが、一度共有（プッシュ）したコミットを取り消すとチームメンバーに迷惑がかかる場合があるため、共有前の履歴操作に留めるのが安全です。 - GitHub以外にもリモートリポジトリは作れますか？
-
可能です。Gitはツールであり、GitHubはサービスの一つに過ぎません。
競合サービスとして「GitLab」や「Bitbucket」がありますし、AWSやAzureなどのクラウドサービス内にもGitホスティング機能（Azure Reposなど）が存在します。どれを使ってもgit pushやgit cloneなどの基本操作は同じです。
