GitHub って何？
18個のリポジトリを数えて分かった、公開と非公開の分け方
Git が手元のセーブなら、GitHub はそのセーブを預けておくネット上の金庫です。自分のリポジトリを全部数え直して、何を公開して、何を隠すべきだったかを振り返ります。
この記事は 2026年10月22日時点の情報です2025年6月18日の夜9時6分。私は GitHub に、test という名前のリポジトリを作りました。
リポジトリは、GitHub の中にあるプロジェクトごとの置き場所です。名前のとおり、試しに作ったものでした。その15分後に、もう一つ。こちらは何かを公開する練習だったようで、名前に「deploy（公開する）」と入っています。
あれから1年4か月。このノートを書くために、自分の GitHub のリポジトリを全部数え直しました。18個ありました。そのうち非公開が14個、公開が4個です。
このノートは「はじめての開発」の2本目です。1本目の「Git って何？」では、手元でセーブして戻す話をしました。今回は、そのセーブをネットの向こうに預ける GitHub の話です。18個を数えながら、何を公開して、何を隠しておくべきだったのかを、実際の出来事で振り返ります。
- Git は手元のセーブ、GitHub はそのセーブを預けておくネット上の金庫。Git だけでも使えるし、GitHub に預けると PC が壊れても残る
- 個人の作品は、まず非公開で作るのが安全。鍵のファイルは、あとから消しても履歴に残る
- 無料プランでも、非公開のリポジトリはいくつでも作れる。ただし無料の GitHub Pages は公開リポジトリだけ
- 18個私の GitHub にあるリポジトリ（2026年10月22日）
- 14個そのうち非公開
- 5分鍵のファイルを入れてから、消すコミットまで
- 1,762個ホラーゲームで、大きなファイル専用の仕組みに預けているファイル
Git と GitHub は、何が違う？
名前がそっくりなので、最初は同じものだと思いがちです。でも、この2つは別ものです。
- Git：変更を記録して、前の状態に戻せるようにする道具。自分の PC の中で動く
- GitHub：Git の記録（リポジトリ）を、ネット上に預けておけるサービス。人と共有したり、作業を頼み合ったりする機能もついている
GitHub の公式ドキュメントも、Git を「いちばん広く使われている分散型のバージョン管理システム」、GitHub を「Git のリポジトリを預かって、開発者がより良いコードを届けるための道具を提供する」ものとして、分けて説明しています。
たとえるなら、Git は手元のセーブデータ、GitHub はそのセーブデータを預けておく貸し金庫です。
実際、私の Fall in Love（いま作っている落下ゲーム）は、Git は使っていますが、GitHub には預けていません。セーブは手元の PC の中にだけあります。それでも、1本目のノートに書いたように、AI が作り直した場面を4分で戻せました。戻すだけなら Git だけで足ります。
では、GitHub に預けると何が変わるのか。いちばん大きいのは、PC の外にもう一つ、同じ記録ができることです。PC が壊れても、ディスクがいっぱいで消してしまっても、GitHub から丸ごと取り戻せます。Fall in Love のセーブは、いまのところ PC が壊れたら一緒に消えます。
ホラーゲームの1日目に、金庫を作った
いま作っているホラーゲームは、2026年9月25日に始めました。その日の作業記録には、エンジンを決めて、開発の道具を入れて、最初の試作を作って、3回遊んで直して、という一日が並んでいます。その中に、こんな一行があります。
GitHub | 非公開リポジトリを作成して push
Git の履歴と GitHub の記録を突き合わせると、順番はこうでした。
- 最初のコミット。Unreal Engine 5.8 で作った最初の試作を、手元の Git でセーブ
- 試作に、操作と演出を足してセーブ
- GitHub に非公開のリポジトリを作る。そこまでのセーブを預ける（push）
- 以降、作業のたびにセーブして預ける
最初の3時間は、Git だけで進めていたことになります。試作がちゃんと動いて、続けられそうだと分かってから、金庫を作った。手元で始めて、あとから GitHub に預ける。この順番で何も困りません。
このゲームは、その後10月6日までに74回セーブしていて、記事を書いている今、まだセーブしていない変更は0件でした。1本目のノートで告白した Fall in Love の「661件」とは対照的です。
預けるものと、預けないもの
ゲームのフォルダには、預けてはいけないものや、預ける必要のないものもたくさんあります。Git では、.gitignore というファイルに「これは記録しない」と書いておきます。ホラーゲームでは、たとえばこんなものを外しています。
| 記録しないもの | 理由 |
|---|---|
| エンジンが自動で作るフォルダ（Binaries、Intermediate、Saved など） | いつでも作り直せる。巨大で、変わるたびに記録がふくらむ |
| 書き出したゲーム本体 | 作品の材料ではなく、できあがった配布物 |
| エディタの個人設定 | PC ごとに違う。他の人には関係ない |
| 骨組みの参照用に書き出したマネキンの3D データ | Epic のテンプレートの素材なので、自分の記録には入れない |
最後の行は、作業記録の「決めたこと」に残っている判断です。手元で参照に使うのはよくても、自分のリポジトリに他人の素材の書き出しを置いておく必要はありません。
大きなファイルは、別の窓口へ
ゲームには、3D のデータや画像のような大きなファイルが山ほどあります。GitHub は、50MiB を超えるファイルを送ると警告を出し、100MiB を超えるファイルは受け付けません。ブラウザから上げる場合は25MiB までです。
そこで使うのが Git LFS（Large File Storage）です。公式の説明では、リポジトリには「ファイルへの参照」だけを置き、本体は別の場所に預ける仕組みです。ホラーゲームでは、Unreal Engine のデータと画像をこの仕組みに回していて、数えると1,762個ありました。無料プランでも、LFS なら1ファイル2GB まで扱えます。
このゲームは「作るのはすべて Claude、私は方向を決める」という分担なので、.gitattributes というファイルに「この拡張子は LFS へ」と書いたのも Claude Code です。最初のコミットから入っていました。
5分後の「Remove sensitive files」
18個のうち、いちばん古い部類のリポジトリに、こんな履歴がありました。2025年8月31日の真夜中です。
00:38 v1.0 - 基本機能完成（会話・口パク・DB・全身立ち絵） 00:43 Remove sensitive files
キャラクターと会話できるアプリの v1.0 をセーブして、5分後に「見られたら困るファイルを消す」コミット。消したのは、.env（API の鍵などを書いておくファイル）と、会話を保存していたデータベースの2つでした。
ここに Git の大事な性質があります。消すコミットをしても、消す前のセーブは履歴に残るんです。1本目で書いた revert と同じで、Git は「消した」という記録を足すだけ。00時38分のセーブを開けば、鍵のファイルはそこにあります。
このリポジトリは、いまは非公開です。でも、もし公開のまま送っていたら、5分あれば誰かに拾われてもおかしくありません。GitHub の公式ドキュメントも、鍵をうっかり入れてしまったときは、履歴を書き換える前に、まずその鍵を無効にするか作り直すこと、と書いています。履歴から消しても、誰かが先に複製（クローン）していたら、その中には残るからです。
鍵は、入れてから消すのではなく、最初から入れない。
防ぎ方は単純で、最初のコミットの前に .gitignore に .env と書いておくことです。たとえばこのサイトでは、2026年10月9日に、公開しない作業用のフォルダ（いまは記事の原稿や点検の道具を置いている場所）を .gitignore に足しました。それ以来、そのフォルダの中身は一度も記録されていません。
公開と非公開、どう分ける？
GitHub のリポジトリには、公開（public）と非公開（private）があります。公式の説明は短くて分かりやすいです。
- 公開：インターネット上の誰でも見られる
- 非公開：自分と、自分が明示的に招いた人だけが見られる
私の18個を、公開と非公開で分けると、こうなりました。
| 数 | 入っているもの（例） | |
|---|---|---|
| 非公開 | 14 | 作りかけのゲーム、iPhone アプリ、Chrome 拡張、SNS のボット、このサイト（2026年10月21日まで公開）、練習用 |
| 公開 | 4 | アプリのプライバシーポリシーのページ、配布用のリポジトリ、試しに公開した小さな道具 |
公開している4個は、どれも「見られて困るものがない」か、「見てもらうために作った」ものです。たとえば YouTube Shooting（Chrome 拡張）のプライバシーポリシーは、公開リポジトリに置いて、GitHub Pages で Web ページとして出しています。利用者に読んでもらうための文章なので、公開で困ることはありません。
それ以外は、全部非公開です。作りかけのゲームの仕様、まだ発表していない仕掛け、ボットの設定。見せる理由がないものは、隠しておくのが基本です。
最初の公開リポジトリは、ブラウザから上げた
公開の4個の中で一番古いのは、YouTube Shooting のプライバシーポリシーのページです。履歴は2行だけです。
2026-01-20 19:31 Add files via upload 2026-01-20 19:42 Rename privacy-policy.html to index.html
1行目の「Add files via upload」は、Git のコマンドを使わず、GitHub のサイト上でファイルをドラッグして上げたときに自動でつく説明文です。GitHub は、ブラウザだけでもファイルを置けます（ただし1ファイル25MiB まで）。
2行目は、その11分後。privacy-policy.html という名前を index.html に変えています。GitHub Pages は、URL の最後にファイル名を書かずに開いたとき、index.html を表示します。名前が違うままだと、ページの住所を開いても中身が出てきません。11分の間に、そこでつまずいて直した記録です。
このページができた2日後の1月22日に、YouTube Shooting の v1.0.0 をセーブしています。拡張機能の本体より先に、ポリシーのページを公開で用意していた順番です。本体のコードは非公開、読んでもらう文章だけ公開。この分け方は、9か月たったいまも同じです。
公開から非公開に切り替えると、何が起きる？
このサイト usuilab のリポジトリは、2026年1月24日に作ってから、10月21日の夜まで約9か月、公開のままでした。無料の GitHub Pages でサイトを出すには、公開リポジトリにしておく必要があったからです。
そのあいだ、困ったことが起きていました。引っ越しの準備でリポジトリを点検したら、告知文の下書きや計測の計画といった内部向けのメモまで、誰でも読める状態だったんです（詳しくは「GitHub と Cloudflare って何が違う？」に書きました）。サイトの公開先を Cloudflare に移したうえで、10月21日20時24分にリポジトリを非公開にし、翌朝そのメモを公開フォルダの外へ移しました。
翌日の10月22日には、YouTube Shooting のコードのリポジトリも非公開にして、このサイトからのリンクを外しています。
公開から非公開に切り替えるとき、GitHub の公式ドキュメントには、こんな注意が並んでいます。
- すでに誰かが作った公開の複製（フォーク）は、非公開にならない。公開のまま切り離される
- スター（お気に入り）とウォッチは、すべて消える
- 無料プランでは、そのリポジトリの GitHub Pages のサイトが自動で止まる
- 独自ドメインを使っていたなら、先に DNS の設定を外すか直す（ドメインを乗っ取られないように）
つまり、一度公開したものは、非公開にしても「なかったこと」にはならないということです。公開していた9か月のあいだに誰かが複製していれば、それは残ります。だから、迷ったら最初は非公開で始めて、見せたいものだけを公開にするほうが、あとで慌てずに済みます。
usuilab のときは、Pages が自動で止まるのを逆手に取って、先に Cloudflare 側でサイトが動くのを確かめてから非公開にしました。順番を逆にすると、サイトがしばらく消えます。
無料でどこまで使える？
個人で始めるなら、GitHub の無料プラン（GitHub Free）で十分です。2026年10月22日に公式の説明で確かめた範囲では、こうなっています。
| 項目 | 無料プラン（個人） |
|---|---|
| リポジトリの数 | 公開・非公開とも無制限 |
| 非公開リポジトリへの招待 | 人数は無制限（使える機能は公開より少なめ） |
| GitHub Pages | 公開リポジトリだけ |
| GitHub Actions（自動で動く処理） | 月2,000分 |
| Git LFS の1ファイルの上限 | 2GB |
有料の Pro プランにすると、非公開リポジトリからも Pages を出せるようになります（サイト自体は公開になります）。私はそこにお金を払う代わりに、サイトの公開を Cloudflare Pages に任せる道を選びました。コードは GitHub の非公開リポジトリに置いたまま、サイトだけを無料で出せるからです。
最初の push まで
手元ですでに Git を使っているフォルダを、GitHub に預けるまでの流れです。
- GitHub のアカウントを作る
- 右上の「＋」から「New repository」を選び、名前を決めて、Private（非公開）を選ぶ
- README や .gitignore を「最初に作る」オプションは付けずに作る（公式ドキュメントのおすすめ。手元のセーブとぶつからないように）
- できあがったページに出る URL を使って、手元のフォルダで次の2行を打つ
git remote add origin <リポジトリの URL> ← 預け先を登録する（最初の1回だけ） git push -u origin main ← 手元のセーブを預ける
2回目からは git push だけで、新しいセーブが預けられます。GitHub の公式コマンドラインツール（gh）を入れているなら、gh repo create で、リポジトリを作るところから預けるところまでを、質問に答えながら一度に済ませることもできます。
main と master
手元の Git の設定によっては、最初のブランチの名前が main ではなく master になっていることがあります。その場合は、上の main を master に読み替えるか、名前をそろえます。
このサイトのリポジトリにも、その跡が残っています。2026年1月24日23時41分に最初のコミットをして、11分後の23時52分に、ブランチの名前を master から main に変えています。GitHub に預けたのはその直後で、GitHub の記録ではリポジトリができたのは23時51分です。最初のセーブ、名前の付け直し、金庫の用意が、10分ほどの間にまとまっていました。
ちなみに Fall in Love のブランチは、今も master のままです。GitHub に預けていないので、困ったことがありません。
AI に頼むなら
私の場合は、ここも AI に頼んでいます。たとえばこう言います。
このフォルダを GitHub に非公開のリポジトリとして預けてください。 その前に、.gitignore を作って、.env や自動生成のフォルダが入らないようにしてください。 預ける前に、記録されるファイルの一覧を見せてください。
最後の一文が大事です。何が金庫に入るのかを、預ける前に一度だけ自分の目で見る。5分後の「Remove sensitive files」は、これで防げます。
このノートの数字は、AI に数えてもらった
冒頭の「18個」は、私が GitHub の画面を一つずつ見て数えたわけではありません。Claude Code に、GitHub の公式コマンドラインツール（gh）で、私のアカウントのリポジトリを一覧にしてもらいました。名前、作った日時、公開か非公開か。それを並べて、古い順に読んでいくと、自分の1年4か月がそのまま出てきます。
- 2025年6月：練習用の
testと、公開の練習 - 2025年8月：キャラクターと会話するアプリ（5分後の「Remove sensitive files」）
- 2026年1月：YouTube Shooting のポリシーのページ、YouTube Shooting の本体、このサイト
- 2026年4月：SNS のボット、iPhone アプリ
- 2026年8〜9月：ブラウザゲーム、ホラーゲーム
GitHub は、コードの金庫であると同時に、自分が何をいつ始めたかの年表でもあります。リポジトリを作るのは、たいてい「これを作るぞ」と決めた日だからです。
同じように一覧を見ると、点検にも使えます。公開になっているものが本当に公開でいいか。長いあいだ触っていないリポジトリに、鍵が入ったままのセーブがないか。私は今回、公開の4個の中身を見直して、どれも「見せるためのもの」で、鍵らしい名前のファイルが入っていないことを確かめました。
GitHub の gh コマンドで、私のアカウントのリポジトリを全部、 作った日時・公開か非公開か・説明文つきで、古い順に表にしてください。 公開になっているものには、中に鍵のファイル（.env など）がないかも確かめてください。
このノートから持ち帰れること
GitHub に限らず、「ネットの向こうに預ける」ときに共通する考え方です。
- 手元の記録と、外の預け先は別ものGit だけでも戻せる。でも PC が壊れたら一緒に消える。大事なものは、手元の外にもう一つ。作品のフォルダ、写真、原稿、仕事のデータのバックアップ
- 迷ったら非公開から始める非公開から公開にするのは簡単。でも公開していた間に複製されたものは、非公開にしても戻らない。GitHub、クラウドの共有フォルダ、SNS の投稿、共有リンク
- 鍵は最初から入れない消すコミットをしても、前のセーブには残る。入ってしまったら、まず鍵そのものを作り直す。API の鍵、パスワード、個人情報を含むデータ
- 預ける前に、中身の一覧を一度見るAI に任せていても、何が入るかだけは自分で確かめる。初めての push、ファイルの共有、提出物のアップロード
- 公開するものは「見せるために作ったもの」だけ私の公開リポジトリ4個は、プライバシーポリシーや配布物のように、読んでもらうためのもの。ポートフォリオ、作品の紹介、配布用のページ
- 公開になっているリポジトリは、本当に誰に見られてもいいものか
.gitignoreに.envなどの鍵のファイルが書いてあるか- 過去の履歴に、鍵やパスワードが入ったセーブがないか（あれば、鍵を作り直したか）
- GitHub に預けていない、手元だけのプロジェクトはないか
やってみよう
記事と同じことを、手元の AI で試せる指示文です。ChatGPT・Gemini・Claude のどれでも使えます。AI は毎回ちがう答えを返すので、記事とまったく同じ条件にはなりませんが、考え方の練習にはしっかり使えます。実際にやってみてください。
練習1自分のプロジェクトの .gitignore を作らせる
次のようなプロジェクトを GitHub に預けようとしています。 （例：Python で作った Discord ボット。API の鍵は .env に書いている。会話のログを sqlite に保存している） このプロジェクトの .gitignore を作ってください。 それぞれの行に、なぜ記録しないのかを一言ずつコメントで添えてください。
.env とデータベースのファイルが入っているか。記事の「Remove sensitive files」で消した2つと同じものが挙がるか。
練習2公開か非公開かを、一緒に決める
私が GitHub に置こうとしているものを並べます。 それぞれ、公開と非公開のどちらにすべきか、理由といっしょに答えてください。 1. 作りかけのゲームの本体 2. スマホアプリのプライバシーポリシーのページ 3. 自分用に作った、SNS の投稿を自動化するボット 4. 個人サイトの HTML（下書きのメモも同じフォルダにある）
4番で「下書きのメモ」に気づいて注意してくれるか。記事の usuilab で実際に起きたことと比べてみる。
練習3鍵を入れてしまったときの手順を聞く
GitHub の非公開リポジトリに、API の鍵が書かれたファイルをコミットして push してしまいました。 5分後に、そのファイルを消すコミットもしました。 これで安全ですか？ 安全でないなら、やるべきことを優先順に教えてください。
「消すコミットだけでは履歴に残る」「まず鍵を無効にして作り直す」が、最初のほうに出てくるか。
出典・参考にした情報
- GitHub Docs「About Git」（Git と GitHub の説明、英語）
- GitHub Docs「About repositories」（公開と非公開、無料プランの非公開リポジトリ、英語）
- GitHub Docs「GitHub's plans」（無料プランと Pro の内容、英語）
- GitHub Docs「Setting repository visibility」（非公開にしたときに起きること、英語）
- GitHub Docs「Removing sensitive data from a repository」（鍵を入れてしまったとき、英語）
- GitHub Docs「About large files on GitHub」・「About Git Large File Storage」（ファイルの大きさの上限と LFS、英語）
- GitHub Docs「Adding locally hosted code to GitHub」（最初の push の手順、英語）
- リポジトリの数・作った日時・公開の状態は、2026年10月22日の自分の GitHub アカウントから。コミットの時刻はそれぞれの Git の履歴、ホラーゲームの1日目は開発の作業記録から
いずれも 2026年10月22日に確認しました。下書きや図づくりには AI を使っていますが、事実関係は自分で確かめてから公開しています。
ウスイ福岡で個人開発をしています。アプリやゲームを作りながら、分かったことをこのノートに書いています。運営者・編集方針