2026年10月8日に、GitHubのリポジトリ説明、ライセンス案内、機密データ削除ガイドを再読しました。GitHubのrepositoryはファイルとrevision historyを扱う場所で、branch・clone・fork・merge・pull request・remoteは別の概念です。公開コードを利用・変更・配布できる条件を示すにはlicenseが必要で、無指定ならcopyrightが残ります。secretが漏れたときは履歴を消す前にrevokeまたはrotateを優先し、既存のclone・fork・cache・共同作業への影響を調整します。リポジトリの履歴は業務データの完全なバックアップや秘密管理を代替しません。
リポジトリは、ファイルとその変更履歴を管理するための保管場所です。この記事では、開発でよく使われるGitのリポジトリを扱います。GitHubのアカウントがなくても、手元のパソコンだけで作り、履歴を残せます。
最初に区別したいのは、ファイルを保存すること、履歴に記録すること、別の場所と共有することです。Gitでは、編集するだけで全変更が自動的に履歴に残るわけではありません。どの状態を記録するかを選び、コミットという操作をします。
30秒で要点
- Gitは変更履歴を扱う道具、リポジトリはその保管場所、GitHubなどは共有やレビューを支えるサービス。
- 保存→ステージ→コミット→プッシュは別の操作。ステージした後の編集は、追加で選ばなければ次のコミットに入らない。
- リモートは「別のリポジトリ」で、同じPC内にも置ける。プッシュしただけでWebサイトが公開されるとは限らない。
- 履歴は復元の材料になるが、未保存の作業、秘密情報、稼働中のデータまで安全に管理してくれる万能なバックアップではない。
図書館の比喩で分かることと、分からないこと
本を整理し、改訂版を残し、必要な人が取り出せる図書館を想像すると、保管の役割は理解しやすくなります。ただし、Gitの履歴は貸出記録そのものではありません。「この時点の内容を残す」と選んだスナップショットが、前の記録とつながっています。
表が収まらない場合は、横にスクロールできます
| 役割 | できること | 自動的には決まらないこと |
|---|---|---|
| 保管 | コード、説明文、設定のひな形を管理する | 何を入れてよいか、秘密を含まないか |
| 履歴 | 記録した状態と現在を比べる | 編集のたびに全部記録すること |
| 取得・共有 | 別の作業場所へ履歴を渡す | 最新状態への常時同期、公開範囲の適切さ |
| 復元の材料 | 過去の記録から内容を取り出す | アプリやデータベースを含む業務全体の復旧 |
文章やコードのようなテキストは差分を読みやすい一方、画像やWord等のバイナリでは中身の変更を通常の行差分で把握しにくいことがあります。何でも置けるから何でも入れる、とは考えません。容量、権利、機密性、更新の仕方に合わせて、別の保管先を選ぶ場合もあります。
手元の作業と、記録と、共有先を分ける
通常のGit作業では、次の3つを区別します。
- 作業ツリー：いま編集しているファイル。
- ステージ（インデックス）：次のコミットに入れるために選んだ内容。
- ローカルの履歴：コミットして保存した記録。
git addは、その時点の内容をステージに置く操作です。その後に同じファイルを編集しても、選び直さない限り、追加の編集はステージへ入りません。コミットはステージの内容を記録します。Pro Gitの変更記録の説明で、この区別が示されています。
普通の作業リポジトリでは、履歴や設定を扱う情報が.gitディレクトリにあります。これを単なる不要フォルダとして削除しないでください。共有用のbareリポジトリなど別の形もあるため、すべてのリポジトリが見た目まで同じとは限りません。
リモートは別のリポジトリを指します。インターネット上のGitHubだけでなく、社内ネットワークや同じPC内の別フォルダも利用できます。Gitのリモートの説明にも、同じマシンに置けることが明記されています。ローカルとリモートは二者択一ではなく、手元で編集して別の場所と共有する組み合わせです。
よく出る言葉を、操作の目的で覚える
表が収まらない場合は、横にスクロールできます
| 用語 | 何をするか | 注意する境界 |
|---|---|---|
| commit | 選んだ内容を履歴に記録する | 未ステージの編集は通常含まれない |
| push | 別のリポジトリへコミット等を送る | 作業フォルダの全ファイルを送る操作ではない |
| fetch | 別の履歴を取得する | 取得だけでは現在の作業へ統合しない |
| pull | 取得した変更を現在のブランチへ統合する | 設定や指定によって方法が変わり、競合や拒否があり得る |
| clone | リポジトリから新しい作業場所を作る | 浅いコピー等の指定、権限、別管理データで取得範囲が変わる |
| fork | GitHub等で元のリポジトリと関係する別リポジトリを作る | Gitのローカルコピー操作そのものとは別のサービス側の機能 |
| branch / merge | 作業の系列を分ける / 変更を統合する | 自動統合できても業務上の正しさは別途確認する |
特にpullは「ダウンロードだけ」ではありません。この後の教材ではgit pull --ff-onlyを使い、履歴が分岐しているときは停止させます。勝手に強制更新して解消する手順にはしていません。git-pullの公式マニュアルの取得・統合とオプションの説明が根拠です。
まずローカルだけで、記録の境界を試す
以下はPowerShellとGitが使える環境向けの、3つを順に実行する教材です。既存のプロジェクトではなく、新しく用意した空の練習フォルダで始めてください。各ブロックが成功したことを確認してから次へ進み、エラーが出たらそこで止めます。実データや認証情報は使いません。
共有先も同じPCのフォルダです。外部サービスへの接続、GitHubのアカウント作成、Webサイト公開は行いません。組織でGit設定や署名が管理されている場合は、その方針に沿う練習環境を使ってください。
1. 作成し、ステージ後の編集を観察する
次を空の練習フォルダから実行します。著者名とメールはこの練習リポジトリだけの仮の値です。global設定は変更しません。
git init -b main work
Set-Location work
git config user.name "Practice User"
git config user.email "practice@example.invalid"
Set-Content -LiteralPath README.md -Value "one" -Encoding utf8
git add README.md
Add-Content -LiteralPath README.md -Value "two" -Encoding utf8
git status --short
git diff --cached
git diff
git commit -m "Record the first line"
git show HEAD:README.md
Get-Content -LiteralPath README.mdステージにはoneが入り、後から足したtwoは作業ファイルだけにあります。最初のコミット直後、git showでは1行、Get-Contentでは2行を確認できます。ここが「保存したから全部コミットされる」との違いです。端末表示の改行やBOMは環境で異なるため、行の内容に注目します。
git diff --cachedはコミットに入る側、引数なしのgit diffはまだステージしていない側を調べる道具です。差分が空でも、別の側に変更が残っていることがあります。
2. 残りの内容を記録し、別の保管場所へ送る
前のブロックの続きで、workにいる状態から実行します。この例のフォルダには練習用READMEだけがあります。実際のプロジェクトでgit add .を使うときは、対象ディレクトリ以下の意図しない追加・変更・削除を含めないか、先にstatusと差分で確認してください。
git status --short
git add .
git diff --cached
git commit -m "Record the second line"
git init --bare -b main ../shared.git
git remote add origin ../shared.git
git remote -v
git push -u origin main
git clone --branch main ../shared.git ../secondshared.gitは共有先の役を持つbareリポジトリです。普通の編集用作業ツリーを持たず、履歴を受け渡すために使います。secondは、そこから作った別の作業場所です。git-initの公式説明の--bareと-bを明示しているので、既定のブランチ名には依存しません。
originは共有先の短い名前で、特別な会社やサービスを指す語ではありません。実サービスではURLを指定する場合がありますが、ここではローカルパスです。共有先を設定して履歴を送る役割を、認証も外部送信も不要な形で確かめています。
3. 別の作業場所の変更を取り込む
引き続きworkから実行します。-Cは指定したディレクトリでGitを実行する指定で、PowerShellの現在位置は変えません。
git -C ../second config user.name "Practice User"
git -C ../second config user.email "practice@example.invalid"
Add-Content -LiteralPath ../second/README.md -Value "from second" -Encoding utf8
git -C ../second add README.md
git -C ../second commit -m "Add a line from the second copy"
git -C ../second push origin main
git pull --ff-only
git log --oneline -3
Get-Content -LiteralPath README.md最後にone、two、from secondの3行と、3つのコミットを確認します。取り込みが拒否されたら、別の変更がないかstatusとlogを調べます。教材の結果に合わせるために実プロジェクトで強制プッシュや履歴削除をする必要はありません。
この練習で確認できるのは、選んだ内容の記録と、ローカルの別リポジトリとの受け渡しです。インターネット越しの認証、共同作業のレビュー、障害復旧、デプロイまで合格したという意味ではありません。
個人・チーム・事業でどう役立つか
表が収まらない場合は、横にスクロールできます
| 利用場面 | 履歴に残す価値 | 一緒に決める運用 |
|---|---|---|
| 個人ブログ | 記事や見た目を変えた理由を追う | どこまで記録し、どの状態を公開するか |
| チームのWebアプリ | 機能の変更を分けて確認し、統合する | ブランチ、レビュー担当、統合前の検査 |
| ECサイト | 決済等のコードの変更経緯を追う | 顧客・注文データと秘密を別管理し、復旧計画を持つ |
| オープンソース | 提案された変更を比較し、協力する | ライセンス、貢献ルール、採否の責任者 |
これらは利用場面の例であり、当社や特定企業の導入実績ではありません。コミットメッセージに「修正」だけを並べるより、何をなぜ変えたかを残すと、比較や原因調査の手がかりになります。ただし履歴だけで不具合の原因が自動確定するわけではありません。
競合をGitが検出しても、どちらの意図を採るかは人が判断します。また、異なる行を自動統合できたとしても、機能同士が矛盾する可能性は残ります。統合後の検査と、公開の判断を省略しないことが必要です。
サービスは、人気より運用条件で選ぶ
表が収まらない場合は、横にスクロールできます
| 選択肢 | 確認する入口 | 比較するときの問い |
|---|---|---|
| GitHub | リポジトリの共有、権限、レビュー | 誰に閲覧・変更・管理を許すか |
| GitLab | GitLab.comとSelf-Managed等の提供形態 | 自分で設置・維持する責任を持てるか |
| Bitbucket Cloud | 作成・取得・共有・レビューの基本操作 | 既存の作業手順と担当者の権限に合うか |
サービス条件は変わるため、価格や「一番人気」を本記事の選定根拠にはしません。GitHubのリポジトリ説明、GitLabの提供形態、Bitbucket Cloudの入門を入口に、必要機能、人数、保存量、検査の実行費、アクセス管理、取り出し方を比較します。各サービスの実アカウント操作はこの記事の確認範囲に含めていません。
作成時には、所有者、名前、公開範囲、README、連絡先を決めます。READMEには目的、必要な環境、動かし方、確認方法を書きます。整理するときも「不要そうだから削除」ではなく、参照先、履歴、担当者、保管義務を確認し、アーカイブ等の選択肢も検討します。
秘密情報と公開・復元の境界を守る
.gitignoreは、意図して追跡しないファイルを対象にする設定です。すでに追跡しているファイルには効かず、過去のコミットも消しません。gitignoreの仕様を踏まえ、パスワードやAPIキー、顧客データは入れる前に管理先を分けます。private設定も、権限や認証が不要になる意味ではありません。
誤って秘密を共有した場合、今のファイルを削除しただけでは不十分です。GitHubの秘密情報削除の説明は、まずその秘密を無効化・交換することと、既存のcloneやfork等に残る限界を示しています。履歴を書き換える操作は他の人の作業にも影響するため、この入門教材では実施しません。
公開リポジトリは、すべての再利用が無条件に許可されるという意味でもありません。ライセンスの公式説明に沿って、LICENSEと利用条件を確認します。閲覧できることと、商用利用や再配布の権利を分けて考えます。
リモートに送った履歴は復元の材料ですが、まだ送っていないコミット、未追跡ファイル、稼働中のデータベース、環境設定などは別です。重要なシステムでは、必要なデータと手順が揃い、別環境で復元できるかを確かめます。同じPC内の練習用リモートは、そのPCの故障への備えにはなりません。
最後に、pushとdeploy（実行環境へ反映する作業）も別です。自動公開が設定されていればpushがきっかけになることはありますが、Git自体がWebサイトの正常動作や公開の承認を保証するわけではありません。
履歴を読めたら、共同作業と公開へ進む
最小の確認は、練習例でステージ側と作業側の差を説明できることです。そのうえで、Gitの基礎、コミット、ブランチ、マージを学ぶと、共同作業の役割がつながります。
公開の工程はデプロイの入門、制作全体の進め方はWebサイト作成入門、コード自体の基礎はプログラミング入門で確認してください。まずは履歴に何が入り、何がまだ入っていないかを、自分で確かめるところから始められます。