Last updated on

GitHub のはじめ方と「上げてはいけないもの」 — 秘密を守る最初の一歩

AI に手伝ってもらってコードを書いたり、自作サイトを作ったり。 できたものを保存・公開する場所として、よく登場するのが GitHub（ギットハブ） です。

とても便利な一方で、初心者がやりがちな事故があります。 秘密の情報まで、一緒に世界へ公開してしまうことです。

この記事では、GitHub の基本の繋ぎ方と、絶対に上げてはいけないものを、あわせて整理します。 「便利に使う」と「うっかり漏らさない」を、最初にセットで身につけましょう。

GitHubへの流れと上げてはいけないもの。手元でコミットしてプッシュするとGitHubに上がる。秘密は.gitignoreで除外し、環境変数で渡す。

GitHub とは

GitHub は、コードやファイルを保存・共有・公開できるサービスです。 できることは、大きく 3 つです。

  • バックアップ:手元のパソコンが壊れても、データが残る
  • 履歴:いつ・どこを変えたかが記録され、いつでも前に戻せる
  • 公開／共有:他の人に見せたり、一緒に作業したりできる

さらに、GitHub に上げた内容をきっかけに、Cloudflare Pages などが自動でサイトを公開してくれる、という連携もよく使われます。 このブログも、その仕組みで動いています。

基本の流れ：commit と push

GitHub とのやりとりは、大きく 2 つの動作で進みます。

commit（コミット） 手元での変更に「ここまでを記録」と区切りをつける操作です。 セーブポイントを作るイメージです。

push（プッシュ） 記録した内容を、手元から GitHub へ送り出す操作です。 プッシュして初めて、GitHub 側に反映されます。

つまり、「手元で作業 → コミットで記録 → プッシュで GitHub へ」。 この流れが基本形です。 AI（Claude Code など）に任せる場合も、裏側でこの流れが動いています。

つなぐまでの、おおまかな手順

はじめて GitHub とつなぐときの流れも、ざっと見ておきましょう。 細かいコマンドは AI に任せられますが、全体像を知っておくと安心です。

  1. GitHub のアカウントを作る
  2. 保存場所（リポジトリ）を GitHub 上に作る
  3. 手元のフォルダと、その保存場所を結びつける
  4. 変更をコミットして、プッシュする

一度つないでしまえば、次からは「コミット → プッシュ」を繰り返すだけです。 はじめの結びつけでつまずいたら、エラー文をそのまま AI に貼って相談すると早いです。

⚠️ 上げてはいけないもの

ここがこの記事の核心です。 GitHub は便利ですが、公開リポジトリに上げたものは、世界中の誰からでも見られます。 次のものは、絶対に上げないでください。

  • パスワード・API キー・アクセストークン
  • サービスアカウントの鍵ファイル（.json など）
  • .env ファイル（秘密の設定をまとめたファイル）
  • 個人情報・顧客から預かったデータ
  • 社外秘の資料

とくにこわいのが、鍵やトークンの類です。 これらは「本人の代わりに操作できる合鍵」なので、他人の手に渡ると、勝手に使われたり課金されたりします。

そしてもう一つ、覚えておいてほしい事実があります。 一度アップロードしたものは、あとで消しても履歴に残りやすく、完全には消えません。 「上げてから消せばいい」は通用しない、と考えてください。

どうやって防ぐか

防ぐ方法は、大きく 2 つです。

1. .gitignore で除外する リポジトリに .gitignore というファイルを置くと、そこに書いたものは「Git の管理から外す＝上げない」と指定できます。 秘密の設定や生成物は、ここに入れておきます。

# 秘密の設定（絶対に上げない）
.env
*.pem
credentials.json

# 生成物・依存（上げなくてよい）
node_modules/
dist/

2. 鍵は「環境変数」で渡す API キーやサービスアカウントの鍵は、そもそもコードの中に書かず、リポジトリの外に置きます。 そして、公開先（Cloudflare Pages など）の環境変数として渡します。

実際このブログでも、GA4 と連携する鍵は Git には一切置かず、Cloudflare 側の環境変数にだけ入れています。 「鍵は Git ではなく環境変数へ」。これが基本の型です。

鍵以外にも、自分専用の設定ファイル（.claude/settings.local.json）や、自動で作られるサムネ画像などの生成物は、このブログのリポジトリでも .gitignore で外しています。 「秘密」と「自動で作り直せるもの」は上げない。この線引きを最初に決めておくと、あとがずっと楽です。

もし上げてしまったら

気をつけていても、事故は起きます。 うっかり鍵を上げてしまったと気づいたら、慌てず、けれど急いで対処します。

いちばん大事なのは、その鍵を「消す」のではなく「無効化して作り直す」ことです。

  1. 漏れた鍵やトークンを、発行元の画面で**すぐ無効化（失効）**する
  2. 新しい鍵を作り直す
  3. 新しい鍵を、環境変数など安全な場所に入れ直す

履歴から完全に消すのは手間がかかるうえ、すでに誰かに見られている前提で動くのが安全です。 古い鍵を無効にしてしまえば、たとえ見られても悪用できません。 いちばん確実な火消しです。

よくある疑問

非公開（プライベート）なら何を上げてもいい？ 基本は安全性が上がりますが、油断は禁物です。 うっかり公開に切り替えたり、共有相手が増えたりすることもあります。 「鍵はそもそも置かない」を徹底するほうが、あとで楽です。

個人開発でも気をつけるべき？ はい。 一人で使うつもりのリポジトリでも、公開設定のミス一つで漏れます。 最初から癖づけておくのが、いちばんの近道です。

何が秘密か分からないときは？ 「これが他人に知られたら困るか」を基準にしてください。 困るなら上げない。 迷ったら AI と安全につきあう の「秘密は入れない」と同じ考え方で判断できます。

まとめ

GitHub は、保存・履歴・公開をまとめて担ってくれる、頼れる置き場所です。 基本は「手元で作業 → コミット → プッシュ」。 これだけ押さえれば、日々の運用は回ります。

そのうえで、忘れてはいけないのが「上げてはいけないもの」。 鍵・パスワード・.env・個人情報は上げない。鍵は環境変数で渡す。 そして、もし上げてしまったら「消す」より「無効化して作り直す」。

便利さと安全は、両立できます。 最初にこの型さえ身につけておけば、AI で作ったものを、安心して世界に公開していけます。 公開したあとの流れは、記事を公開したら最初にやることへどうぞ。