前回の続き——履歴はどこにまとまるのか
前回のO-01では、変更履歴を保存して比較・復元・分岐できる仕組みを、バージョン管理と呼ぶことを学びました。ではその履歴は、いったいどこにまとまって保存されるのでしょうか。今回学ぶリポジトリが、その入れ物にあたります。バージョン管理という考え方を、実際に手を動かす単位へと落とし込む最初の一歩です。まずは「どこからどこまでが1つの管理単位なのか」という感覚をつかんでいきましょう。
このスライドのポイント
- O-01: 変更履歴を保存し、比較・復元・分岐できる仕組み＝バージョン管理
- 残った問い: その履歴は、どこにひとまとまりで保存されるのか
- 今回のリポジトリ＝その履歴とファイルをまとめて収める入れ物
- ねらい: 「どこからどこまでが1つの管理単位か」の感覚をつかむ
リポジトリの定義
リポジトリとは、プロジェクトのファイル一式と、その全履歴をまとめた管理単位のことです。B-04で学んだプロジェクトフォルダに、変更の履歴が付いたものだと考えてください。履歴はフォルダの中の隠し領域である.gitに保存されていて、普段の作業では直接目にすることはありません。そして原則は、1つのプロジェクトにつき1つのリポジトリです。この単位がはっきりしていることで、バージョン管理の効き目が及ぶ範囲が明確になります。
このスライドのポイント
- リポジトリ＝プロジェクトのファイル一式と、その全履歴をまとめた管理単位
- B-04のプロジェクトフォルダに、変更の履歴が付いたもの
- 履歴はフォルダ内の隠し領域（.git）に保存され、普段は直接見えない
- 原則: 1プロジェクト＝1リポジトリ
なぜ管理の単位を意識するのか
リポジトリの範囲があいまいだと、どこからどこまでが管理されているのかが分からなくなります。よくある事故が2つあります。1つは、リポジトリの中にうっかり別のリポジトリを作ってしまい、履歴が二重になってしまう事故です。もう1つは、本来は無関係な複数のプロジェクトを1つのリポジトリに混ぜてしまい、履歴がからまって切り分けられなくなる事故です。どちらも、管理の単位をあらかじめ意識していれば防げるものです。
このスライドのポイント
- 範囲があいまいだと「どこまでが管理されているか」が分からない
- 事故1: リポジトリの中に別のリポジトリを作り、履歴が二重になる
- 事故2: 無関係な複数プロジェクトを1つに混ぜ、履歴がからまる
- どちらも「管理の単位」を意識すれば防げる
リポジトリの断面
リポジトリの中身を断面で見てみましょう。表側には、いつも編集している作業ファイルの一式があります。その裏側、.gitという隠し領域に、これまでの全履歴が保存されています。私たちが普段見ているのは表側の作業ファイルだけですが、裏側に履歴があるからこそ、過去の状態と比べたり、そこへ戻したりできます。注意点として、フォルダごと削除してしまうと、この.gitの中の履歴も一緒に消えてしまいます。履歴は作業ファイルと同じ入れ物の中にある、という点を覚えておいてください。
このスライドのポイント
- 表側: いつも編集している作業ファイルの一式
- 裏側: 隠し領域.gitの中に保存された全履歴
- 普段見えるのは表側だけ／裏側があるから比較も復元もできる
- 注意: フォルダごと削除すると.gitの履歴も一緒に消える
経費アプリのリポジトリと、入れてはいけないもの
具体例として、経費アプリのリポジトリを考えます。中身は、アプリのコードと設定ファイル、そしてそれらの変更履歴です。ここで大切な注意があります。B-09で学んだ.env、つまり秘密情報を書いたファイルは、履歴に入れてはいけません。除外指定のための.gitignoreというファイルに書いておくことで、履歴から守ります。一度履歴に入った秘密情報は、後から消すのがとても難しく、B-09で警告した事故がここで現実になってしまいます。だからこそ、最初から履歴に入れないことが肝心です。
このスライドのポイント
- 経費アプリのリポジトリ＝コード＋設定＋その変更履歴
- B-09の.env（秘密情報）は履歴に入れてはいけない
- .gitignore（除外指定）に書いて、履歴から守る
- 一度履歴に入った秘密は消しにくい——B-09の事故がここで確定する
技術サンプル——git status で現状を見る
種別はcommand、目的はリポジトリの現状把握です。サンプルは git status の1本だけです。このコマンドを実行すると、いま管理対象になっているファイルの状態が表示されます。読み方の要点は3つです。1つ、statusは状態を見るだけの読み取り専用コマンドで、何も壊しません。2つ、まだ管理対象でないファイルはUntrackedと表示されます。3つ、作業はまず現状把握から始めるのが安全です。AIへの質問例は「このリポジトリの.gitignoreに、秘密情報（.env等）は含まれていますか」です。
フォルダとリポジトリの違い
混同しやすいのが、フォルダとリポジトリの違いです。B-04で学んだフォルダは、ファイルをまとめるためのただの入れ物でした。一方リポジトリは、そこに全履歴という管理の仕組みが加わったものです。やっかいなのは、画面上では両者が同じフォルダに見えることです。見た目は同じでも、.gitがあるかないかで、履歴を持つ管理単位なのか、ただの入れ物なのかが分かれます。自分がいま扱っているのがどちらなのかを、意識する習慣をつけましょう。
このスライドのポイント
- フォルダ（B-04）: ファイルをまとめるただの入れ物
- リポジトリ: そこに全履歴という管理の仕組みが加わったもの
- 画面上はどちらも同じフォルダに見える
- 分かれ目は.gitの有無＝履歴を持つ管理単位かどうか
バイブコーディングでの確認点
バイブコーディングでの確認点です。新しいプロジェクトを始めるときは、AIへ2つのことをセットで頼む定型を持ちましょう。1つはリポジトリの初期化、もう1つは.envを除外する.gitignoreの作成です。この2つを最初に済ませておけば、履歴を残す準備と、秘密情報を守る準備が同時に整います。A-09で学んだ「元に戻せる変更」を支える土台を、プロジェクトの最初の一手で用意しておく、という考え方です。
このスライドのポイント
- プロジェクト開始時、AIへ2つをセットで頼む定型を持つ
- ①リポジトリの初期化 ②.envを除外する.gitignoreの作成
- 履歴を残す準備と、秘密を守る準備を同時に整える
- A-09「元に戻せる変更」の土台を、最初の一手で用意する
まとめと次回
最後に一問一答です。履歴に絶対入れてはいけないファイルの代表は何でしょうか。（間）答えは.env、つまり秘密情報を書いたファイルです。.gitignoreで除外して守ります。30秒でまとめます。リポジトリはファイルと全履歴をまとめた管理単位で、原則は1プロジェクト1リポジトリ、そして秘密情報は履歴に入れない、この3点が要点です。次回は、変更が履歴になるまでの3つの段階を見ていきます。関連資料は「Git・GitHub 完全入門」と「環境変数・APIキー管理入門」です。
このスライドのポイント
- 一問一答: 履歴に絶対入れてはいけないファイルの代表は？
- 答: .env（秘密情報。.gitignoreで除外して守る）
- 30秒まとめ: リポジトリ＝ファイル＋全履歴の管理単位／原則1プロジェクト1リポジトリ／秘密は履歴に入れない
- 次回: 変更が履歴になるまでの3段階へ
- 関連資料: 「Git・GitHub 完全入門」「環境変数・APIキー管理入門」
