Git基礎 | n10u-tech bootcamp

Gitはソースコードの変更履歴を管理する分散型バージョン管理システムである。「どのファイルを・いつ・誰が・なぜ変更したか」をすべて記録し、任意の時点に戻ることができる。チームでの共同作業だけでなく、一人での開発でも変更を安全に追跡できる。

Pythonのデータ分析で例えると、JupyterノートブックのCell実行履歴ではなく、「プロジェクト全体のファイル群のスナップショット」を積み重ねていくイメージに近い。

コラム: commit は「差分」ではなく「スナップショット」と考える

Git は内部的には、前回との差分だけを保存しているように見えても、使う側は「その時点のファイル群全体の状態」を commit として積み重ねていくと考えた方が分かりやすい。だからこそ、任意の時点へ戻る、branch を切る、変更を比較する、といった操作が一貫して扱える。

この見方を持つと、「1 commit には 1 意図だけを入れる」理由も見えやすい。後から履歴を読んだとき、そのスナップショットが何を目的にしたものかをすぐ判断できるからである。

概念リンク

Pro Git: スナップショットであり差分ではない（https://git-scm.com/book/ja/v2/Git%E3%81%AE%E5%9F%BA%E6%9C%AC-%E3%82%B9%E3%83%8A%E3%83%83%E3%83%97%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%E3%81%A7%E3%81%82%E3%82%8A%E5%B7%AE%E5%88%86%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84）
Atlassian: Saving changes（https://www.atlassian.com/git/tutorials/saving-changes）

書籍

『Pro Git 第2版』: Git の内部モデルをつかむ定番
『Gitポケットリファレンス』: 手元ですぐコマンドを引ける実用寄りの一冊

基本概念

リポジトリ（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 を使う。

この章で手を動かすときの確認

この章は導入編の STEP 3にある「手を動かす」の章です。本文を読み終えたあと、次の観点だけ確認すると次へ進みやすくなります。

この章で確認すること:

commit / branch / merge の基本操作を実行できる
小さい変更を履歴として残す意味を理解する

次に活きる章:

GitHubワークフロー
Issue ベースの開発フローを回す

対応する完成条件（checklist.yml）:

補助参照:

Git と GitHub の基本フローに慣れる