学ぶ｜Web開発入門 #2

Gitの基本を独学で身につける完全ガイド｜コミット・ブランチ・コンフリクト解決まで

  • Git
  • GitHub
  • Web開発入門
  • プログラミング未経験
📋 この記事の目次
  1. Gitは「ゲームのセーブポイント」だと考える
  2. Part A: Gitの基本概念と環境構築
  3. Part B: 基本コマンド完全ガイド
  4. Part C: ワークフローとブランチ
  5. Part D: ベストプラクティス
  6. 実践プロジェクト：自己紹介カードをGitで管理する
  7. 🧠 理解度チェック（一部抜粋）
  8. 挫折ポイントTOP3と対処法
  9. この先、何を学べばいいか
  10. まとめ
  11. 🎓 理解度テスト

前回、HTML/CSSで自己紹介カードを作りました。ここでよくある悩みが出てきます。

「profile.htmlを編集していたら、前のバージョンの方が良かった気がする…でも上書きしてしまってもう戻せない」 「profile_v2.html、profile_v2_最終.html、profile_v2_最終_本当の最終.htmlとファイルが増えていく」 「共同開発の現場で『ブランチ』『コミット』『プルリクエスト』という単語が飛び交うが、何のことか分からない」

これらをまとめて解決するのがGit（バージョン管理システム） です。今回は、自己紹介カードのソースコードをGitで管理しながら、仕組みから実務で使うブランチ運用まで一気に押さえます。

Gitは「ゲームのセーブポイント」だと考える

Gitの本質は、ゲームのセーブ機能に近いたとえで理解できます。

  • コミット（commit） = 「ここまでの進捗をセーブする」操作
  • ブランチ（branch） = 「同じセーブデータから分岐した、別ルートの攻略」
  • マージ（merge） = 「分岐した2つの攻略ルートの成果を1つにまとめる」
  • プッシュ（push） = 「セーブデータをクラウド（GitHub）にアップロードする」

上書き保存しかできないファイル管理と違い、Gitは 「いつでも過去のセーブポイントに戻れる」「本編を壊さずに新しい機能を試せる」 という安心感を与えてくれます。

🧓 ベテランの現場コラム Gitを知らない新人が最初にやりがちなのが、ファイル名でバージョン管理する「なんとか_最終版.html」問題です。これ自体は悪気があるわけではなく、“戻れる場所”を作る手段を知らないだけです。Gitはまさにこの「戻れる場所を作る」ための道具だと理解すると、コマンドの意味がすっと入ってきます。

Part A: Gitの基本概念と環境構築

Gitが解決する問題

  • 誰が・いつ・何を変更したかの記録が残る
  • 複数人が同時に同じファイルを編集しても、変更を統合できる
  • 「動いていた頃」の状態にいつでも戻せる

重要な用語

用語 意味
リポジトリ（repository） プロジェクトの変更履歴が入った保管庫
ワーキングツリー 実際に編集しているファイル群
ステージングエリア 「次のセーブに含める変更」を一時的に置く場所
コミット ステージングエリアの内容を1つの記録として保存する操作
リモートリポジトリ GitHub等、クラウド上に置いた共有先の保管庫

Gitのインストールと初期設定

# インストール確認
git --version

# 名前とメールアドレスの登録（コミット記録に使われる）
git config --global user.name "Yamada Koji"
git config --global user.email "you@example.com"

GitHubリポジトリの作成と接続

GitHub上で空のリポジトリを作成したら、自己紹介カードのフォルダと接続します。

cd profile-card
git init
git remote add origin https://github.com/your-account/profile-card.git

Part B: 基本コマンド完全ガイド

保存の流れ（add → commit）

git status              # 現在の変更状況を確認
git add index.html      # 変更をステージングエリアに追加
git add .                # すべての変更をまとめて追加
git commit -m "自己紹介カードの初期バージョンを作成"

「addでステージに乗せ、commitで確定保存する」という2段階になっているのは、関係のない変更を一緒にコミットしてしまわないための仕組みです。

同期のコマンド

git push origin main     # ローカルの変更をGitHubへ送る
git pull origin main      # GitHub側の変更をローカルへ取り込む
git fetch                 # リモートの状態だけ確認する（自動では取り込まない）

確認のコマンド

git log                   # コミット履歴を確認
git log --oneline          # 1行ずつ簡潔に表示
git diff                   # 直前の変更内容を確認

🧓 ベテランの現場コラム 「とりあえずgit add .」は便利ですが、実務では意図しないファイル（一時ファイルや秘密情報を含む設定ファイルなど）まで巻き込んでコミットしてしまう事故の温床にもなります。コミット前に必ずgit statusで「何が含まれるか」を確認する癖をつけましょう。

Part C: ワークフローとブランチ

ブランチの操作

git branch add-dark-mode        # 新しいブランチを作成
git switch add-dark-mode        # ブランチを切り替える
git switch -c add-dark-mode      # 作成と切り替えを同時に行う

自己紹介カードに「ダークモード機能」を試作したいとき、mainブランチ（本番相当）を直接触らず、add-dark-modeのような作業用ブランチを切って進めます。うまくいけばmainにマージし、失敗してもmainは無傷のままです。

マージとコンフリクトの解決

git switch main
git merge add-dark-mode

同じ行を2つのブランチで別々に変更していると、Gitが自動統合できず「コンフリクト（衝突）」が発生します。

<<<<<<< HEAD
<h1>やまだこうじ</h1>
=======
<h1>Koji Yamada | Engineer</h1>
>>>>>>> add-dark-mode

この表記は「どちらを残すか自分で選んでください」というGitからのメッセージです。不要な行を削除し、<<<<<<<・=======・>>>>>>>の記号自体も消してから、改めてgit add→git commitで解決を確定させます。

実践的な運用フロー

  1. mainから作業ブランチを切る
  2. 作業ブランチでコミットを積み重ねる
  3. GitHub上でプルリクエスト（変更内容のレビュー依頼）を作成する
  4. レビューが通ったらmainにマージする

一人開発でもこの流れに慣れておくと、チーム開発に移ったときに戸惑いません。

Part D: ベストプラクティス

  • コミットメッセージ: 「何を」「なぜ」変更したかが分かる一文にする（例: 自己紹介カードにダークモード切替を追加）。「修正」「update」だけの記録は後で見返しても意味が分からなくなる
  • ブランチ命名規則: feature/dark-mode、fix/typo-headerのように「種類/内容」の形式にすると一覧性が上がる
  • .gitignoreの設定: パスワードや一時ファイルなど、リポジトリに含めたくないファイルを指定する
# .gitignore の例
.env
node_modules/
.DS_Store
*.log
  • README.mdの作成: プロジェクトの目的・セットアップ方法を書いておくと、数ヶ月後の自分や他の人が助かる
  • コミット頻度: 「キリの良い機能単位」でこまめにコミットする。1日分の変更を1つの巨大なコミットにまとめない

実践プロジェクト：自己紹介カードをGitで管理する

  1. profile-cardフォルダでgit initし、最初のコミットを作成する
  2. GitHubにリポジトリを作り、pushして公開する
  3. feature/dark-modeブランチを切り、前回作ったカードにダークモード用のCSSを試作する
  4. mainにマージし、意図的に同じ行を編集してコンフリクトを起こし、解決する練習をする
  5. .gitignoreとREADME.mdを整備する

🧓 ベテランの現場コラム 一人で開発しているとブランチを切る意味を感じにくいかもしれませんが、「あとで消せる前提の作業スペース」を持てることには大きな価値があります。思い切った変更を試して失敗しても、mainブランチにさえマージしていなければ、そのブランチごと削除すれば何事もなかったことにできます。

🧠 理解度チェック（一部抜粋）

  • Q. git addとgit commitはなぜ分かれているのか？ → 関係のない変更を誤って一緒に確定保存しないようにするため
  • Q. コンフリクトが起きるのはどんなときか？ → 複数のブランチで同じ箇所を別々に変更し、Gitが自動統合できなかったとき
  • Q. .gitignoreに書くべきものは？ → パスワード等の秘密情報、自動生成される一時ファイル、OS固有のファイル

挫折ポイントTOP3と対処法

1. 「pushしようとしたら拒否された」問題

リモート側に自分がまだ取り込んでいない変更がある場合に起きます。git pullで最新を取り込んでから、改めてgit pushします。

2. 「コンフリクトの解消方法が分からない」問題

慌てず、エディタで該当ファイルを開き、<<<<<<<〜>>>>>>>の間から残す内容を選んで記号ごと削除、その後git add→git commitで完了です。

3. 「間違えて秘密情報をコミットしてしまった」問題

.gitignoreは「これから追跡するファイル」にしか効きません。すでに追跡してしまったファイルはgit rm --cachedで追跡対象から外す必要があります（履歴に残った内容自体を消すにはさらに踏み込んだ対応が必要になるため、コミット前の.gitignore設定が何より重要です）。

🧓 ベテランの現場コラム 「エラーメッセージが英語で読む気が失せる」という声をよく聞きますが、Gitのエラーメッセージは実はかなり親切です。git pushが拒否されたときも「まずpullしてください」という趣旨の案内が表示されています。エラーの全文を諦めずに読む癖は、Git以外のあらゆるトラブルシューティングでも役立ちます。

この先、何を学べばいいか

自己紹介カードのソースをGitで管理できるようになったら、次はサーバー側の処理を学ぶ「Python」 に進みます。Gitで管理する対象が、静的なHTML/CSSだけでなくPythonのプログラムにも広がっていきます。

まとめ

  • Gitは「戻れる場所を作る」ための道具。上書き保存の不安から解放される
  • add→commit→pushの流れと、status/log/diffでの確認を体に覚えさせる
  • ブランチは「本番を壊さない実験スペース」。うまくいけばマージ、失敗すれば消せばよい
  • コンフリクトは事故ではなく「自分で選ぶ場面が来た」というだけの通知
  • .gitignoreとコミットメッセージのルールは最初に整えておく

参考にした学習リソースについて

本記事は、ハーバード大学が提供する人気講座「CS50’s Web Programming with Python and JavaScript」の内容を参考にしつつ、独自の題材・独自の構成・自作のサンプルで書き下ろしたオリジナル解説記事です。CS50そのものに興味を持った方は、以下の公式サイトも覗いてみてください。

🎓 理解度テスト

学んだ内容を確認しましょう。全6問。