- 扱うこと：新しいメンバーに Git を教えるとき、
.gitignoreをどの順番で教えるか、安全に確かめる方法 - 扱わないこと：
.gitignoreの書き方の詳しい解説（.gitignore の基本の記事で扱っています） - 前提：Git をインストール済みで、
git initしたフォルダがあること（ダミーのファイルだけで試せます） - ゴール：最初のレッスンで「記録しないファイル」を決め、
git statusとgit check-ignoreで確かめられるようになること
用語：リポジトリは Git が変更の記録をためる場所、コミットはその記録の1回分、追跡（トラッキング）は Git がそのファイルを記録の対象にしている状態のことです。
この記事は、チームや勉強会で「Gitを初めて触る人」に最初の1回を教える立場の方に向けて書いています。読み終わると、最初のレッスンで何をどの順番で見せればよいか、そのまま使える台本とコマンド、うまくいかないときの直し方がそろいます。
Gitの研修というと、git add と git commit から始めることが多いですよね。でも、初心者がいきなり git add .（フォルダの中を全部まとめて記録の候補に入れるコマンド）を覚えると、.env（APIキーなどの設定を書くファイル）やログまで一緒に入ってしまいがちです。
そこで私がおすすめしたいのは、add の前に .gitignore（Gitに「このファイルは記録しないで」と伝えるリスト）を一緒に作る順番です。「何を記録しないか」を先に決めておけば、そのあとの git add を安心して試せます。
なぜ .gitignore が最初なのか
プロジェクトのフォルダには、ソースコードのほかに、OSやツールが自動で作るファイル、ログ、そしてAPIキーなどを書いた .env が混ざります。特に .env は、一度コミットして公開すると、あとから完全には取り消せません。だから私は、記録の方法より先に「記録しないもの」を決めてもらいます。
最初に.gitignoreを学ぶと、「何を記録しないか」を決めてから git add に進めます。記録してよいものを先に区別しておくことで、うっかりの登録を減らしやすくなります。
ポイントは、git add . で .env がステージ（記録の候補に入ること）され、そのまま commit すると履歴に残る点です。あとから .env を消しても履歴には残るので、漏れたキーは発行元で無効化して再発行することになります。右の流れでも、commit の前に git status と git diff --cached（ステージした中身を表示するコマンド）で、入れるファイルを目で確かめる手順は省きません。
「追加」より先に「除外」を学ぶ意味
たとえば、.gitignore がないフォルダで git status --short（変更の一覧を短く表示するコマンド）を打つと、こんなふうに見えます（ファイル名は例です）。
- 1
- 2
- 3
?? .env
?? app.py
?? debug.log?? は「まだ記録の対象になっていない新しいファイル」という意味です。この状態で git add . すると、.env も debug.log も全部候補に入ります。.gitignore に .env と *.log を書いてから同じコマンドを打つと、一覧に残るのは app.py と .gitignore だけになります。レッスンでは、この「前と後」を画面で見せるのがいちばん伝わります。
app.py と .gitignore（このファイル自体は共有するので記録します）が残ります。すでに記録したファイルは素通りします。.gitignore は、書いたルールに当たるファイルだけを git add . から外すフィルターです（図では node_modules/ も書いた例にしています）。書いていない名前の秘密ファイル（例：credentials.json）は素通りしますし、すでに追跡しているファイルにも効きません。git add の前後に git status で一覧を目で確かめる習慣はそのまま残しましょう。
具体的に何を「無視」するのか
.gitignore はふつうリポジトリのいちばん上（.git フォルダと同じ場所）に置き、除外したい名前を1行ずつ書きます。書く対象は、下の図3の4種類に分けると覚えやすいです。
新しいメンバーに教えるときは、この4つを全部覚えてもらう必要はありません。最初のレッスンでは「機密情報ファイル（.env など）」を一番先に扱い、残りの3つは「自動で作られるものは入れない」とまとめて伝える順番がおすすめです。具体的な書き方はチームのGitが毎日荒れる意外な原因、実は「.gitignore」にあった？、そのまま使える例はプロが使う.gitignoreパターン集｜現場で効くテンプレにまとめています。GitHubが公開している言語別のテンプレート（github/gitignore）を使って始めるのもよい方法です。
なお、自分だけのエディタの一時ファイルなどは、core.excludesFile（標準は ~/.config/git/ignore）という個人用の除外設定に書けます。ただし、ここに書いたルールはチームに共有されません。.env のように全員で除外したいものは、必ずリポジトリの .gitignore に書きます。
最初のレッスンで一緒に確かめること
.gitignore は書いただけでは確かめられません。ダミーのファイルを作って、Git から本当に除外されているかを一緒に見るのがおすすめです。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
# ダミーの .env を作る（中身は本物の値ではなく例だけ）
echo "API_KEY=dummy" > .env
echo ".env" >> .gitignore
# .env が「追跡されていないファイル」に出てこないことを確かめる
git status
# どの行のルールで除外されているかを表示する
git check-ignore -v .envgit check-ignore -v は、ファイルが除外されているとき、どの .gitignore の何行目が効いているかを表示します。新しく作った .gitignore の1行目に .env を書いた場合は、次のように出ます。
- 1
.gitignore:1:.env .env左から「ルールが書かれたファイル：行番号：ルール」、最後が確かめたファイル名です。何も表示されなければ、そのファイルは除外されていません。
除外されているファイルを一覧で見たいときは git status --short --ignored を使います。除外中のファイルには !! が付きます。
もう1つ、レッスンで必ず見せてほしいのが「すでに記録したファイルには効かない」場面です。一度コミットした .env は、.gitignore に書いてあっても git check-ignore -v .env が何も表示しません。追跡（記録の対象）が続いているからです。ルールそのものが当たっているかだけを確かめたいときは、git check-ignore -v --no-index .env のように --no-index を付けます。
- すでに追跡されているファイルは、あとから
.gitignoreに書いても除外されません。git rm --cached ファイル名で追跡を外す必要があります（手順は.gitignore の基本の記事）。 - 過去のコミット（履歴）に入ってしまった内容は、
.gitignoreでは消えません。 - 本物のパスワードやAPIキーをコミット・push してしまったら、まずそのキーを発行元で無効化（失効）して作り直すのが先です。履歴の書き換えだけでは、すでにコピーされた分は取り戻せません。
-
.gitignoreは書いた名前にしか効きません。git add .の安全を保証するものではないので、git statusでの確認と組み合わせます。 - 公式の説明：Git - gitignore Documentation、Git - git-check-ignore Documentation、GitHub Docs：ファイルを無視する、GitHub Docs：リポジトリからの機微なデータの削除
最初のレッスンの進め方（そのまま使える4ステップ）
- 練習用フォルダを作る：本番のプロジェクトではなく、
git initした空のフォルダで始めます。ダミーのapp.py、debug.log、.env（中身はAPI_KEY=dummy）を置きます。 - 何もしないで status を見る：
git status --shortで、3つとも??で出ることを確認します。「このままgit add .したら.envも入るね」と一緒に言葉にします。 - .gitignore を書いて、もう一度見る：
.envと*.logの2行を書き、git status --shortとgit check-ignore -v .envを打ちます。消えたファイルと、効いている行番号を確かめます。 - わざと失敗を見せる：
git add .envを打つと「The following paths are ignored by one of your .gitignore files」と表示され、追加されないことを見せます。ここで-f（強制）を付けると入ってしまうので、使わない約束もしておきます。
この4つが終わってから、git add と git commit に進みます。
よくある失敗と直し方
- .gitignore に書いたのに status に出続ける：すでに追跡しているファイルです。
git rm --cached .envで追跡だけを外し（手元のファイルは消えません）、git diff --cachedで「.env の削除」だけがステージされているのを確かめてからコミットします。注意：この変更をほかのメンバーが取り込むと、その人の手元で追跡中だった.envも削除されることがあります（手元に変更がある場合は、Gitが取り込みを拒否することもあります）。先に各自で.envの控えを取ってもらうよう伝えてから行いましょう。 - .env を push してしまった：最初にやるのは、キーを発行元で無効化して再発行することです。追跡を外しても（
git rm --cached）、.gitignoreに書いても、過去のコミットからは消えません。git log --all -- .envで、手元の履歴のうち、この場所の.envを変更したコミットを一覧できます。ほかの名前や場所に書いた秘密、他の人のクローンやサーバー上のコピーは対象外なので、これで秘密が残っていないことの確認にはなりません。履歴そのものの書き換えは別の作業で、共同作業者との調整が必要なので、キーの失効を済ませたあとにチームで相談します。 - ファイル名の書き間違い：
git check-ignore -v ファイル名で何も出なければ、ルールが当たっていません。スペルと、.gitignoreを置いた場所（ふつうはリポジトリのいちばん上）を見直します。 - チームで必要な設定項目まで共有できなくなる：値を空やダミーにした
.env.exampleを作ってコミットし、本物の.envだけを除外します。.envというルールは.env.exampleには当たりません（逆に.env*と書くと当たってしまいます）。 -
!で戻したのに除外されたまま：親のフォルダごと除外していると、中のファイルを!で戻せません。config/ではなくconfig/*と書いてから!config/sample.ymlを足します。 - サブフォルダの .env まで除外される：
.envはどの階層の.envにも当たります。いちばん上だけにしたいときは、いちばん上の.gitignoreに/.envと書きます（先頭の/は、その.gitignoreがあるフォルダが基準です）。
ここまでの流れを1枚にまとめると、次の図のようになります。
まとめ
この記事では、最初のレッスンで .gitignore から教える順番と、その台本・確かめ方を紹介しました。
-
.envのような秘密のファイルを、git addの前に除外する -
git status --shortとgit check-ignore -vで、除外できたかを目で確かめる - すでに追跡しているファイルや履歴には効かないこと、
git add .の安全までは保証しないことも、最初に伝えておく
戦い方を教える前に、まず防具の着け方を教える、というのが私の考えです。git status と git check-ignore で一緒に確かめるところまでを、最初のレッスンにするのがおすすめです。
次の一歩
-
.gitignoreの書き方と、すでにコミットしてしまったファイルの外し方を知る：チームのGitが毎日荒れる意外な原因、実は「.gitignore」にあった？ - そのまま使えるテンプレートを用意する：プロが使う.gitignoreパターン集｜現場で効くテンプレ
- Gitそのものが初めての方は：Git入門｜init・add・commit を1回やってみる
AIに相談するときの例：
- 1
- 2
- 3
- 4
- 5
- 6
新しいメンバー向けに、このプロジェクトの .gitignore を一緒に作りたいです。
- 使っているもの：（例）Python、VS Code、Mac
- 絶対に入れたくないもの：.env、ログファイル
- 各行が何を除外しているか、初心者にもわかるコメントを付けてください
- 作ったあとに git check-ignore -v で確かめる手順も教えてください
（本物のキーやファイルの中身は貼らず、ファイル名だけ伝えます）