読書メモに機能を足す前に、今あるものを記録します。変えた箇所を読み、試作の履歴を残し、共有先へ渡す。この順序が分かると、AIの変更を受け取るときの不安が減ります。
この回は、しくみを読むことと、実際の結果を確かめる練習を組み合わせます。付属見本はブラウザーだけで保存する一人用の版です。アカウント・データベース・共有は拡張課題として扱います。
差分とコミット：何を変えたかが残る
まちの読書メモに、読了日を入れる欄を足すことにします。AIが完成したと言っても、画面に欄があるだけでは受け取れません。もともとの追加ボタンが動くか、日付を空にしても保存できるか。その確認と一緒に、どのファイルが変わったかを見ます。Gitは、その前後をたどる道具です。
台所の世界でGitは試作ノートです。ただし、手書きの感想と違い、ファイルの状態を記録します。リポジトリは、その履歴を管理するまとまりです。アプリを置いたフォルダにGitを用意しておくと、変更を重ねても以前の記録と比べられます。最初は練習用フォルダ一つだけを管理対象にします。
まずgit statusで、変更されたファイル、新しくできたファイル、次の記録に選ばれたファイルを確認します。ここで見慣れないファイルが多ければ、先へ進まず理由を尋ねます。依頼した日付欄と関係のない画像や設定が混じっていないか。変更の行数より、今回の目的に合う範囲かを見ます。資料 GIT_RECORD
変更を選んで記録する
作業中の変更を読み、次の記録に入れる範囲を選んでからコミットします。ステージした後の追加編集は、別の変更として残ることがあります。
- 手元で編集
- 差分を読む
- 対象を選ぶ
- 選んだ差分を読む
- コミット
- 未追跡ファイルは、本文を開いて確認します。
- ブラウザやデータベースの記録は、Gitの対象とは別です。
git diffは、通常、まだ記録対象に選んでいない変更を行単位で見せます。追加と削除の印が付くので、日付欄を足したのか、既存の入力欄を消したのかが分かります。ただし、新しい未追跡ファイルの本文は、この表示だけでは確認できません。ファイルを開いて内容も見ます。資料 GIT_DIFF
全部のコードを理解する必要はありません。まずファイル名と画面の変化を対応させます。日付欄の変更なのに、外部へ送信する処理が加わったら、なぜ必要かを聞きます。AIには差分を説明させられますが、その説明と実際のファイルが一致するかは、画面と短い動作確認で自分でも確かめます。
次の記録に入れる変更を選ぶ操作がステージングです。git addで対象を選び、git diff --stagedでその内容を見ます。選んだ後に同じファイルを編集すると、選択済みの状態と手元の最新状態がずれることがあります。記録する直前にもう一度見るのは、このずれを残さないためです。資料 GIT_RECORD
コミットは、選んだ状態に説明を付けて履歴へ記録する操作です。『更新』だけで済ませず、『読了日の入力を追加』のように、後から探せる言葉にします。一つのコミットに検索、会員登録、配色変更をまとめると、どこから問題が入ったか追いにくくなります。小さい目的ごとに記録しましょう。資料 GIT_RECORD
記録前には、秘密の設定値や公開したくないメモが含まれていないかも確認します。共有する予定がなくても、あとから履歴を送る可能性があります。除外したいファイルはgitignoreで指定できますが、すでに追跡中のファイルは、その指定だけで追跡から外れません。設定値の混入があれば記録を止めます。資料 GIT_IGNORE
Gitに残るのは、選んで記録したファイルの履歴です。ブラウザに保存した読書記録や、別のデータベースの内容まで自動で戻るわけではありません。どの状態を残せたかを言葉で説明できれば、試作ノートとして使い始められます。データの保存と復元は第7章で別に扱います。
AIに差分を説明してもらう
読了日を追加した変更について、変更ファイルと各ファイルの目的を説明してください。
まだコミットもpushもしません。未追跡ファイルを含め、今回と無関係な変更を挙げてください。
読了日を空にした場合と入力した場合を、既存の追加・削除操作と合わせて確認する方法を示してください。
手を動かす順番
- 変更する前の状態を残す
- git statusと差分で対象を確かめる
- 一つの目的に対応する変更だけを選ぶ
- 選択済みの差分と動作を確認して記録する
ブランチとpush：共有と公開の間を見る
日付欄はできましたが、一覧の並べ方を二通り試したくなりました。新しい順にする案と、書名の順にする案です。元の状態に戻れるかが心配なら、試す作業の履歴をブランチで分けます。Gitのブランチは、あるコミットを指す名前です。試す変更を重ねると、その名前が指す場所も進みます。資料 GIT_BRANCH
ブランチを分ければ、完成した案を比べやすくなります。ただし、通常の同じ作業フォルダでは、切り替えによってそこに見えるファイルが変わります。独立した二つのフォルダが自動で増えるわけではありません。未記録の編集が残っていると、切り替えに影響することもあるので、現在地と変更状態を先に見ます。
ブランチ名は、何を試すかが分かるように付けます。読了日の順に並べるなら、reading-date-sortのような名前で十分です。AIに頼む際は、作業するブランチと変更範囲を決めます。既存の別作業を片付けさせる必要はありません。今ある変更をそのまま残し、今回の案をどう分けるか相談します。
共有から公開までの条件
pushは共有先への送信です。その後の検査と配置は、対象ブランチや起動条件を設定した場合に進みます。最後は公開URLで操作を確認します。
- コミット
- push
- 設定した条件
- 検査と配置
- 公開URLで確認
- 自動公開を設定していないプロジェクトでは、pushの後に別の操作が必要です。
- 確認用URLと本番URLを取り違えないようにします。
できた変更を別のブランチへ取り込む操作がマージです。二つの作業が同じ部分を直すと、どちらを残すか決められず、衝突の解決が必要になることがあります。AIが提案した解決で両方の機能が残ったか、もう一度動かします。文字の衝突が消えたことと、使い方が正しくつながったことを分けて確かめます。
GitHubなど離れた場所に置くリポジトリを、リモートと呼びます。pushは、ローカルのコミットやブランチの情報を、その共有先へ送る操作です。台所のたとえなら、試作ノートの控えを本店の書庫へ預けます。どの共有先の、どのブランチへ送るかを指定し、送信先の公開範囲も確認します。資料 GIT_PUSH
pushが拒否されたら、共有先に自分の手元にない記録があるかもしれません。Gitは通常、共有先の履歴を失う更新を拒否します。拒否を消すためだけに強制送信を選ぶと、他の変更を押しのける場合があります。先に両方の履歴を調べ、取り込み方を決める。エラーは、この順序に戻るきっかけです。資料 GIT_PUSH
pushのあと公開まで自動で進むかは、プロジェクトの設定次第です。たとえばGitHub Actionsは、pushなど指定した出来事で処理を起動できます。どのブランチ、どのファイル変更を対象にするかも設定できます。共有先へ届いたというGitの結果だけから、本番のアプリまで変わったとは判断できません。資料 CI_EVENTS
読書メモでは、確認用の画面で試し、必要な検査を通し、公開対象へ配置し、公開URLで操作する順を決めます。自動処理があっても、対象ブランチが違う、検査が失敗した、承認待ちになったなどの理由で途中に止まることがあります。どこまで進んだかを、処理の記録と実際のURLで照合します。
最終確認では、公開URLで新しい日付欄を使い、保存し、再表示します。違う端末で見たときも確認します。『pushできた』、『配置できた』、『読者が使える』をそれぞれ記録すると、次にどこを直せばよいかが見えてきます。公開の仕組みは第10章で、手順を決めながらもう一度見ます。
送信前に確認すること
まちの読書メモの送信先とブランチ名を、値を変更せず説明してください。
push後に公開処理が始まる設定はありますか。起動条件と確認用・本番の違いを示してください。
送信が拒否された場合は、強制送信せずに止まり、共有先と手元の履歴の違いを説明してください。
手を動かす順番
- 現在のブランチと未記録の変更を確認する
- 試す目的に名前を付けて履歴を分ける
- 送信先と公開処理の起動条件を読む
- 処理の結果と公開URLの操作を照合する
演習：日付欄の変更を一つの記録にする
自分の練習用プロジェクトで、読了日の追加という目的に対応する差分を読みます。共有先への送信は、送信先と公開設定を説明できた後に検討します。
- 変更されたファイルを挙げ、読了日と関係する理由を一行ずつ書く。
- 未追跡、未選択、選択済みの変更の違いを、現在の状態に当てはめる。
- 記録の説明文を作り、Gitに含まれないデータの保存先も書く。
- push後に自動処理が始まる条件を調べ、設定がなければその事実を記す。
解答例を読む
同じ日付欄の変更でも、画面、入力チェック、保存の処理に分かれる場合があります。各ファイルの役割を対応させれば、対象を判断できます。
コミットには選択済みの状態が入ります。未追跡ファイルや、選択後に編集した部分は別に確かめます。
『読了日の入力を追加』のような説明なら、あとから履歴を探せます。読書データの復元は、ブラウザやデータベースの仕組みで考えます。
pushの成功だけでは公開を確定できません。起動条件、検査、配置、公開URLの結果を確認します。
この回で確かめること
- 変更されたファイルを挙げ、読了日と関係する理由を一行ずつ書く。
- 未追跡、未選択、選択済みの変更の違いを、現在の状態に当てはめる。
- 記録の説明文を作り、Gitに含まれないデータの保存先も書く。
- push後に自動処理が始まる条件を調べ、設定がなければその事実を記す。