Git基礎
バージョン管理の仕組みを理解し、コミット・ブランチ・マージの基本操作を習得する
Gitはソースコードの変更履歴を管理する分散型バージョン管理システムである。「どのファイルを・いつ・誰が・なぜ変更したか」をすべて記録し、任意の時点に戻ることができる。チームでの共同作業だけでなく、一人での開発でも変更を安全に追跡できる。
Pythonのデータ分析で例えると、JupyterノートブックのCell実行履歴ではなく、「プロジェクト全体のファイル群のスナップショット」を積み重ねていくイメージに近い。
基本概念
リポジトリ(Repository): Gitが管理するプロジェクトの単位。.git/ ディレクトリが存在するフォルダがリポジトリ。
コミット(Commit): ある時点のファイル群のスナップショット。コミットには「メッセージ」(変更の説明)と一意なハッシュ(a3f9c2dのような文字列)が付く。コミットの積み重ねがプロジェクトの歴史を形成する。
ステージング(Staging): コミットに含めるファイルを選ぶ中間エリア。変更したすべてのファイルを一度にコミットするのではなく、関連する変更だけを選んでコミットできる。
基本ワークフロー
# リポジトリの初期化 or クローン
git init # 新規作成
git clone https://github.com/... # 既存リポジトリをコピー
# 変更の確認
git status # 変更されたファイルを確認
git diff # 差分を表示
# ステージングとコミット
git add src/index.ts # 特定ファイルをステージ
git add . # 全変更をステージ
git commit -m "feat: ユーザー認証を追加" # コミット
# リモートとの同期
git push origin main # リモートに送信
git pull origin main # リモートから取得
ブランチ
ブランチは開発の「作業ライン」を分岐させる仕組みである。main(またはmaster)ブランチが本番に近い安定したコードで、新機能の開発は別ブランチで行うことで、本番コードを汚さずに実験できる。
git branch # ブランチ一覧
git branch feature/user-auth # 新規ブランチ作成
git checkout feature/user-auth # ブランチを切り替え
git checkout -b feature/user-auth # 作成 + 切り替えを同時に
git merge feature/user-auth # 現在のブランチに指定ブランチをマージ
git branch -d feature/user-auth # ブランチを削除
コンフリクト(競合)
複数人が同じファイルの同じ箇所を変更してマージしようとすると、Gitは自動解決できずコンフリクトを報告する。
<<<<<<< HEAD
const greeting = "Hello";
=======
const greeting = "Hi";
>>>>>>> feature/update-greeting
<<<<<<<から=======が現在のブランチの変更、=======から>>>>>>>がマージしようとしているブランチの変更。どちらか(または両方を組み合わせた形)を残して、マーカー行を削除してからコミットする。
.gitignore
バージョン管理から除外するファイル・ディレクトリを指定するファイル。node_modules/(依存ライブラリ)や .env(秘匿情報)は必ず除外する。
node_modules/
.env
.env.local
dist/
.DS_Store
コミットメッセージの慣習
チームでの可読性を高めるため、Conventional Commitsという規約が広く使われている:
feat: 新機能の追加
fix: バグの修正
docs: ドキュメントのみの変更
refactor: 機能変更なしのコード整理
test: テストの追加・修正
chore: ビルドツール・設定変更
参考リソース
- Pro Git(https://git-scm.com/book/ja/v2)— 公式ドキュメント、日本語訳あり・無料公開
- Conventional Commits(https://www.conventionalcommits.org/ja/)
git log --oneline --graph— コミット履歴をグラフで可視化する便利なコマンド
確認クイズ
Q1. Gitのリポジトリを示すディレクトリはどれか。 A. .git/ B. .gitignore C. node_modules/ D. .env
正解: A. .git/
解説: .git/ ディレクトリが存在するフォルダがGitリポジトリとして認識される。このディレクトリにはコミット履歴やブランチ情報などGitが管理するすべてのメタデータが格納されている。
Q2. Gitにおける「コミット」とは何か。
正解: ある時点のファイル群のスナップショット
解説: コミットには変更の説明(メッセージ)と一意なハッシュ(a3f9c2d のような文字列)が付く。コミットの積み重ねがプロジェクトの歴史を形成し、任意の時点に戻ることができる。
Q3. ステージング(Staging)の目的として正しいものはどれか。 A. コードを本番環境にデプロイするための準備 B. コミットに含めるファイルを選ぶ中間エリア C. ブランチをマージする前の確認フェーズ D. リモートリポジトリと同期する処理
正解: B. コミットに含めるファイルを選ぶ中間エリア
解説: 変更したすべてのファイルを一度にコミットするのではなく、関連する変更だけを選んでコミットできる仕組み。git add コマンドでステージングエリアにファイルを追加し、その後 git commit でコミットを作成する。
Q4. 既存のGitリポジトリをローカルにコピーするコマンドはどれか。 A. git init B. git pull C. git clone D. git fetch
正解: C. git clone
解説: git clone https://github.com/... で既存のリポジトリをローカルにコピーできる。git init は新規リポジトリの作成、git pull は既存の追跡ブランチからの取得に使う。
Q5. ブランチを新規作成すると同時に切り替えるコマンドはどれか。 A. git branch feature/xxx B. git checkout feature/xxx C. git checkout -b feature/xxx D. git merge feature/xxx
正解: C. git checkout -b feature/xxx
解説: -b オプションを付けることでブランチの作成と切り替えを1コマンドで行える。git branch feature/xxx は作成のみ、git checkout feature/xxx は既存ブランチへの切り替えのみを行う。
Q6. コンフリクトが発生する条件はどれか。
正解: 複数人が同じファイルの同じ箇所を変更してマージしようとしたとき
解説: Gitは変更箇所が異なる場合は自動でマージできるが、同じ場所を別々に変更した場合はどちらを採用すべきか判断できずコンフリクトとして報告する。手動でどちらの変更を残すか(または組み合わせるか)を決めてマーカー行を削除してからコミットする。
Q7. コンフリクトマーカー <<<<<<< HEAD から ======= の間に表示されている内容はどれか。 A. マージしようとしているブランチの変更 B. 現在のブランチの変更 C. 共通の祖先(ベース)の内容 D. リモートリポジトリの最新内容
正解: B. 現在のブランチの変更
解説: <<<<<<< HEAD から ======= が現在のブランチ(HEAD)の変更を示し、======= から >>>>>>> がマージしようとしているブランチの変更を示す。どちらか(または両方を組み合わせた形)を残してマーカー行を削除し、再コミットする。
Q8. .gitignore に node_modules/ を追加する理由はなぜか。
正解: 依存ライブラリはコードではなく package.json から再インストールできるため、バージョン管理に含める必要がないから
解説: node_modules/ は膨大な数のファイルを含みリポジトリサイズが爆発的に増大する。package.json と package-lock.json(または pnpm-lock.yaml)があれば npm install で再現できるため、バージョン管理から除外するのが慣習となっている。
Q9. Conventional Commitsの規約において fix: プレフィックスが表すものはどれか。 A. 新機能の追加 B. バグの修正 C. ドキュメントのみの変更 D. ビルドツールの設定変更
正解: B. バグの修正
解説: Conventional Commitsでは feat: が新機能、fix: がバグ修正、docs: がドキュメント変更、chore: がビルドツール・設定変更を表す。チームでの可読性を高め、CHANGELOGの自動生成にも活用される。
Q10. git push origin main と git pull origin main の違いを説明してください。
正解: git push はローカルの変更をリモートに送信し、git pull はリモートの変更をローカルに取得する
解説: push はローカルで作成したコミットをリモートリポジトリ(origin)の main ブランチに送信する操作。pull は逆に、リモートの最新状態をローカルに取得してマージする操作。チーム開発では他のメンバーの変更を取得する際に pull を使う。
生きているコード
本ドキュメントで扱ったパターンの完全な動作コードは、メンター側リポジトリの参照ブランチで確認できます。
- 対応 Week: W1
- 参照ブランチ:
- W1:
reference/week-1 - 対応 checklist 項目: N8
ブランチの作り方・見方は b00-curriculum-map を参照してください。
- 1. 📄Web とは何か
- 2. 📄URL を打ってから画面が表示されるまで
- 3. 📄ネットワーク基礎(TCP/IP・DNS・HTTPS)
- 4. 📄【発展】物理層から通信が成立するまで(電力・Ethernet・Wi-Fi・Bluetooth)
- 5. 📄WSL2・Docker セットアップ詳細(Windows 向け)
- 6. 📄環境構築の段階的導入(macOS / Windows)
- 7. 📄カリキュラム全体マップ(Week × 教材 × 参照ブランチ × 要求チェックリスト)
- 8. 📄このカリキュラムの使い方(SQL・Python・Dify経験者向け)
- 9. 📄シェル・ターミナル基礎
- 10. 📄Windows で完全にゼロから始める開発環境構築(Week 1)
- 11. 📄Git基礎
- 12. 📄GitHubワークフロー
- 13. 📄パッケージ管理(pnpm workspace)
- 1. 📄AWSインフラ基礎
- 2. 📄AWS Budget Alert の設定(Month 5 Week 17)
- 3. 📄環境変数管理
- 4. 📄Bastion EC2 と SSH ProxyJump(Month 5 Week 18)
- 5. 📄CI/CD基礎
- 6. 📄ECR への Docker イメージ push と App EC2 デプロイ(Month 5 Week 19)
- 7. 📄テスト設計の基本
- 8. 📄CloudFront + S3 + ALB で公開する(Month 5 Week 20)
- 9. 📄CLAUDE.md・プロジェクト設定
- 10. 📄PR レビュー 5 観点ルーブリック(全 Week 共通)
- 11. 📄タスク分解・仕様の書き方
- 12. 📄Playwright で E2E テスト(Month 6 Week 22)
- 13. 📄生成コードのレビュー・デバッグの勘所
- 14. 📄Trivy で脆弱性スキャン(Month 6 Week 23)
- 15. 📄CloudWatch Logs の読み方と運用(Month 6 Week 23)
- 16. 📄PDF ポートフォリオの自動生成(Month 6 Week 24)