ファイルを無視することと良い習慣
weather-app というプロジェクトをクローンして、npm install を実行し、新しいリポジトリのステータスを確認します。
$ git status
Untracked files:
(use "git add <file>..." to include in what will be committed)
node_modules/
dist/
.env3 つのフォルダとファイルが未追跡として表示されますが、どれもコミットに含めるべきではありません。node_modules/ は npm install が package.json から数秒で再生成する数千ものファイルです。dist/ はソースから毎回再構築されるビルド出力です。そして .env は API キーを保持しています。これらはどれもプロジェクトの履歴に入るべきではなく、考えずに git add . を入力するとそうなってしまいます。
Git に無視するものを告げる
.gitignore ファイルは、Git が追跡すべきではないファイルとフォルダのパターンを一覧にします。プロジェクトのルートに一度作成します。これは、最初のリポジトリでリポジトリをセットアップするときに git init を実行した場所と同じです。その後、git status と git add . は一致するものをひっそりとスキップします。
# .gitignore
node_modules/
dist/
.env各行はパターンです：dist/ のようなプレーンなフォルダ名はそのフォルダ全体を無視し、プロジェクトのどこに表示されても無視されます。 .gitignore ファイル自体をコミットします。それは小さく、プロジェクトをクローンしたすべての人に役立ち、ソースコードと同じ方法で履歴に属しています。
$ git status
On branch main
nothing to commit, working tree cleanパターンが配置されると、git status は静かになります。それはまさにポイントです：コミットしたくないフォルダとファイルがノイズとして表示されなくなるので、表示されるものは実際に重要なものです。
.gitignore ファイルは、Git が追跡すべきではないものを一覧にします：node_modules/、dist/、.env はほぼすべてのプロジェクトの常識です。プロジェクトをクローンした全員が同じクリーンなステータスを取得するように、.gitignore ファイル自体をコミットしてください。私は一度、事故で数千の依存ファイルをステージングしてこれを学ぶ前に一日中を無駄にしました。 シークレットをコミットしない
API キー、データベースパスワード、または署名証明書はコミットに表示されるべきではありません。 これはプライベートリポジトリと同じくらい公開リポジトリに保持され、最初のコミットからずっと保持されます。シークレットを .env のようなファイルに入れ、初日に .gitignore にそのファイルを追加し、ソースファイルに書き込む代わりに値をそこから アプリケーションにロードします。
# .env
WEATHER_API_KEY=sk_live_9f8e7d6c5b4a# .gitignore
.envこのルールを自動的に、毎回、例外なしに従ってください。コミットに存在するキーはリポジトリへのアクセス権を持つ人なら誰でも到達でき、公開リポジトリでは誰でも。
.env のようなファイルに保持し、git add を実行する前に .env を gitignore に追加してください。これはこの章全体で絶対として扱う価値のある 1 つのルールです。 追跡後に .gitignore にファイルを追加する
これはほぼすべての人を少なくとも一度は引っかかる落とし穴です。誤ってファイルをコミットし、間違いに気付き、.gitignore に追加します（以下の echo 行はそのファイルにパスを追加します）。Git がそれを忘れることを期待します。それはしません。
$ git add config/settings.json
$ git commit -m "Add app settings"
# 後で、これが間違いだったことに気付きます
$ echo "config/settings.json" >> .gitignore
$ git status
On branch main
nothing to commit, working tree cleangit status はクリーンなツリーを表示しますが、config/settings.json はまだ追跡されており、将来のすべての git log とすべてのクローンに引き続き表示されます。無視ルールは Git がまだ知らないファイルにのみ適用されます。 ファイルが追加されてコミットされたら、それは履歴の一部であり、.gitignore は履歴に既に存在するファイルに対して何も言うことはありません。
実際に今後の追跡を停止するには、Git にディスク上のファイルを残したまま、追跡するファイルを削除するよう指示してください：
$ git rm --cached config/settings.json
$ git commit -m "Stop tracking config/settings.json"git rm --cached <file> は、作業ディレクトリから削除することなく、Git の追跡からファイルを削除します。その削除をコミットすれば、そこから .gitignore パターンは最初に求めていた仕事をします。
.gitignore にファイルを追加することはそのファイルに対して何もしません。無視ルールは Git がまだ追加していないファイルにのみ適用されます。事故で滑り込んだファイルの追跡を停止するには、git rm --cached <file> を実行してその変更をコミットしてください。 良い習慣：小さなコミットとクリーンなリポジトリ
きれいな .gitignore は、リポジトリを価値あるものにするの半分です。もう半分はコミットをどのように形成するかです。各コミットを 1 つのフォーカスした変更にします：バグ修正、1 つの小さな機能、1 つのリファクタリング。午後の仕事が複数の関連のないものに触れる場合、日の終わりにすべてを 1 つにドロップする代わりに複数のコミットに分割してください。
$ git add src/weather-widget.js
$ git commit -m "Fix temperature rounding in weather widget"小さなコミットは確認が容易で、何か壊れた場合は復帰が容易で、6 か月後に戻ってコード行が存在する理由を思い出すときは読むことが容易です。コミットループ は有用なコミットメッセージを構成するものをカバーしています。この習慣は変更自体を十分に小さく保つことで、良いメッセージを書くことさえ可能にすることです。
.gitignore を保ちます。これらの 2 つの習慣は、リポジトリを楽しく働く理由のほとんどです。小さな習慣は早期に形成されるので、後で多くのクリーンアップを保存します。