GitHubに絶対pushしてはいけないファイル

今回はですね、開発者ならもう絶対に知っておくべきGitHubにプッシュしちゃいけないファイル、これについて詳しく見ていこうと思います。 これ本当にあなたのキャリアとか、あとお財布を守るための知識なんで、ぜひ最後まで見ていってください。 さあ、早速いきましょう。 エンジニアだったら一度は聞いたことあるかもしれない、マジで背筋が凍る話ですよね、これ。 ただいつも通りGit Pushしただけなのに、気づいたらAWSからとんでもない額の請求書が、なんて。 便利なGitHubですけど、たった1つのほんのちょっとしたミスが、こういう悪夢につながっちゃう可能性があるんですよ。 この一言、もう全てを物語ってますよね。先輩が血の気を失った顔でこう言ってきたら、もう終わりだって思いますよ。 これって単なるプログラムのバグとかそういう話じゃないんです。現実世界で、もう直接的にお金の問題とか、会社の信用問題に関わる、めちゃくちゃ深刻な事態なんですよね。 はい、じゃあまず、絶対に、もううっかりでは済まされない、一番やばいファイルから見ていきましょう。 僕これを「死のファイル」って呼んでるんですけど、これを公開しちゃうのはもうキャリアにとって致命傷になりかねない、それぐらいの覚悟で聞いてください。 このスライドの表見てください。これもう地雷原マップですよ。 危険度全部マックスじゃないですか。 特にこの.envファイル、APIキーとかパスワードとか、システムの心臓部の情報が丸ごと入ってるんです。 これをもしGitHubに公開しちゃったら、世界中にいる悪いボットがほんの数秒で見つけ出して、あなたのAWSアカウントで勝手にビットコインのマイニングとか始めちゃうんですよ。 SSHキーも同じ、サーバーの合鍵をインターネットにばらまいてるようなものですからね。絶対ダメです。 でもここでめちゃくちゃ大事なプロの技があるんですよ。 .envファイルは絶対にプッシュしない。 その代わりに、.env.exampleっていうファイルを作るんです。 これは、キーの名前だけ書いて、中身のパスワードとかは空っぽにしとく設計図みたいなファイルですね。 これをリポジトリに入れとけば、チームの新しいメンバーが、「あ、このプロジェクトはこういう設定が必要なんだな」って一発でわかる。 これ本当に素晴らしい習慣なんでぜひ真似してください。 さて、次はセキュリティリスクとまではいかないんですけど、リポジトリをとにかく汚してチーム開発の効率をめちゃくちゃ下げる、いわばゴミみたいなファイルたちです。 僕これを「ゴミ屋敷部門」と呼んでます。 どうです？このスライドにあるファイル、見覚えありませんか？ 特にこいつ、node_modules。この巨大なフォルダーにイライラしたこと一度はあるでしょう？ これってnpm installってコマンド一発で誰でも作れるものだから、リポジトリに入れる意味が全くない。むしろ容量を圧迫するだけ。 他にもMacの.DS_Storeとか、個人のエディター設定とかは、他の人からしたらただのノイズでしかない。 コミット履歴を綺麗に保つのもプロのたしなみですからね。 じゃあ、こういう危険なファイルとか、散らかるゴミファイルをどうやってリポジトリに入れないようにするのか？ その答えが、この最強の盾、.gitignoreファイルなんです。 やり方は超シンプル。プロジェクトの一番上の階層に.gitignoreっていう名前のファイルを作って、そこにGitに無視してほしいファイルとかフォルダーの名前を1行ずつ書いていくだけ。 node_modulesみたいなモンスターも、OSが生み出す小さなゴミも、この盾が全部弾いてくれます。 ここに書かれたものは、git add .をやってももうステージングされなくなるんですよ。 シンプルだけど、効果は絶大です。 さらに一歩進んだテクニック、知りたいですか？ 例えば.DS_Storeみたいに、どのプロジェクトでも絶対に入れたくないファイルってありますよね。それをプロジェクトごとにいちいち設定するの地味に面倒じゃないですか？ そこで使えるのが、自分のPC全体で有効になる共通の無視リストを作るっていう技です。 これがまた驚くほど簡単なんです。 まず、自分のPCのホームディレクトリーに共通で使う無視リスト用のファイルを作ります。 で、そこに.DS_Storeとかを書き込んでおく。 あとはターミナルでこのコマンドを1回だけ実行するだけ。 これでGitに「これからはこのグローバルなリストもちゃんと見てね」って教えられる。たったこれだけで、これから作る全てのプロジェクトで自動的にこれらのファイルが無視されるようになります。 いや、これめちゃくちゃ便利ですよ。 いやいや、自分で書くのもちょっと面倒だなあっていう僕みたいなズボラなあなたに朗報です。 gitignore.ioっていう、もう神みたいなウェブサービスがあるんですよ。 自分の使っているOSとかプログラミング言語とかフレームワークをポチポチ選ぶだけで、あなたのプロジェクトに最適な.gitignoreファイルを一瞬で生成してくれるんです。 これはもうブックマーク必須ですね。 さて、ここからがもしかしたら今日一番大事なパートかもしれません。 「やばい、やっちゃった、もうプッシュしちゃった」っていう、もう絶望的な状況になった時のための冷静でかつ正しい対処法です。 パニックにならないで聞いてください。 いいですか？何よりも、何よりも先にやること、それはこれです。 リポジトリからファイルを消すことじゃありません。 まず、漏れてしまったキーをAWSとかの管理画面で無効化する、もしくは新しいキーに再発行する。これが最優先です。 なんでかっていうと、さっきも言った通り、攻撃者のボットは公開されたキーを秒単位で探し出して悪用し始めます。まさに一刻を争う状況なんです。 パニックになると、みんなやりがちな間違いがあるんです。それが、慌てて問題のファイルを消して、その変更をgit pushしちゃうこと。 でもこれじゃ全く解決になってないんです。 さあ、なんでだかわかりますか？ そう、答えはGitがスナップショットで履歴を管理してるからです。 Gitって変更があった部分だけを記録するんじゃなくて、コミットするたびにプロジェクト全体の写真を撮って保存していくイメージなんです。 だからファイルを削除するっていうコミットは、単にファイルが消えた状態の新しい写真を1枚追加しただけ。 悪意のある攻撃者は、過去のアルバムをペラペラめくるみたいに、古い履歴をたどって秘密がばっちり映ってる昔の写真を簡単に見つけ出せちゃうんです。 秘密はリポジトリの歴史の中に地層みたいに埋まってるんですよ。 履歴から完全にファイルを消し去るには、歴史を改変するっていうちょっと特殊な操作が必要になります。 昔使われてたコマンドはもう非推奨なんで、今は、このスライドにあるようなもっと安全で高速な専用のツールを使うのが常識です。 これらのツールの指示に従えば、過去の全ての歴史、つまり全コミットから問題のファイルを抹消することができます。 この言葉、今回のテーマの核心を突いてますよね。Gitは確かに僕たちの試行錯誤とか失敗の記録を残してくれる素晴らしいツールです。 でも、公開してはいけない秘密っていう「消せない汚れ」を刻むための場所じゃないんです。 クリーンで安全なリポジトリを維持することって、チームのためだけじゃなくて、未来の自分を助けることにもつながるんです。プロの開発者の証とも言えますね。 さあ、この話を聞き終わったら、何をしますか？ そう、今すぐご自身のプロジェクトの.gitignoreファイルを見直してみてください。 今日から始めるこの小さな習慣が、未来の大きな安心につながりますから。安全で快適な開発ライフを送りましょう。