Dev Study
← 解説「コミットしてよいもの・いけないもの — .gitignoreの考え方」に戻る

サンプルコードで身につける: コミットしてよいもの・いけないもの — .gitignoreの考え方

解説で学んだ概念を、5つの具体例で確認します。素朴な例から実務寄りの例へと進みます。

1ng new が設定済みの .gitignore を読む

ng new はプロジェクト作成時に .gitignore も用意します。中身は「コマンドで再現できるもの」と「個人環境のファイル」の除外で、自分で書き足さなくても基本は整っています。

# ng new が生成する .gitignore(主要部分)

# コンパイル結果 → ng build で再現できる
/dist
/tmp
/out-tsc

# 依存ライブラリ → npm install で再現できる
/node_modules

# IDEやエディタの個人設定
.idea/
.vscode/*
!.vscode/settings.json

# OSが勝手に作るファイル
.DS_Store
Thumbs.db

2なぜ node_modules をコミットしないのか

node_modules は package.json と package-lock.json さえあれば npm install で完全に再現できます。数万ファイル・数百MBにもなるため、コミットするとリポジトリが壊滅的に重くなります。

# node_modules の実態を見てみる
du -sh node_modules
# => 450M  node_modules   (数百MB・数万ファイル)

# しかしこの中身は、2つのファイルから完全に再現できる:
#   package.json      … 何を使うかの宣言
#   package-lock.json … 正確なバージョンの記録
npm install
# => node_modules が復元される

# クローンした直後に npm install するのはこのため。
# 「レシピ(2ファイル)を共有し、料理(node_modules)は各自作る」

3package-lock.json は全員の台帳

package.json のバージョン指定には幅があり、install の時期によって入るバージョンが変わり得ます。lock ファイルが正確なバージョンを固定するので、必ずコミットします。

# package.json の指定には「幅」がある
#   "@angular/core": "^20.1.0"
#   → ^ は「20.x の範囲で新しいもの」の意味。
#     install する時期によって 20.1.2 や 20.3.0 が入り得る

# package-lock.json は実際に入れた正確なバージョンを記録する
#   "@angular/core": { "version": "20.1.2", ... }

# lock をコミットしておけば、全員・CIサーバーまで同じ構成になる。
# CIでは lock どおりに入れる npm ci を使うのが定番
npm ci

# lock を消す/コミットしないと「自分の環境だけ動かない」の温床になる

4秘密情報は絶対にコミットしない

APIキーやパスワードをコードに直書きしてプッシュすると、削除しても履歴に残り続けます。秘密の値はコミット対象外のファイルや環境変数に置き、コードには含めないのが原則です。

// ── やってはいけない例 ──
export const config = {
  apiUrl: 'https://api.example.com',
  apiKey: 'sk-abc123-honmono-no-key', // ×: 秘密情報の直書き
};
// 一度プッシュすると、後で消しても過去の履歴には残り続ける。
// 公開リポジトリなら数分でボットに収集されると考えるべき

// ── 基本の考え方 ──
// ・コミットするコードには接続先などの「公開してよい値」だけを書く
// ・APIキーなどの秘密は、コミット対象外のファイルや
//   ビルド時の環境変数から渡す(置き場所はチームで決めておく)
// ・もし誤ってプッシュしたら、削除ではなくキーの無効化・再発行が先

5git status で除外が効いているか確かめる

gitignore が正しく効いていれば、git status に node_modules や dist は現れません。ビルド直後に status を見て生成物が出てこないことを確認するのが手軽なチェック方法です。

# ビルドして dist/ を作ってみる
ng build

# git status に dist や node_modules が出てこなければ除外は有効
git status
# On branch feature/favorite-button
# Changes not staged for commit:
#   modified:   src/app/app.html
# → src/ の変更だけが見えている。これが正常な状態

# あるファイルが無視されているか個別に調べる
git check-ignore -v dist/my-app/main.js
# .gitignore:4:/dist    dist/my-app/main.js
# → .gitignore の4行目の /dist ルールで除外されている、と分かる