確かめられる単位で順に進める

作業を、確かめられる状態で終わる小さな単位の列にする。今の単位の検査が通るまで、次へ進まない。

なぜ: 原因の単位で見つけた破損は、場所を絞るのが安い。まとめた後に見つけた破損は埋もれていて、壊れた土台の上に既に積んでいる。同じ単位を読み手が追える順に並べると、「信じてください」が「落ちて、直って、通るのを見てください」に変わる。

適用する場面:

• 多くのファイルにまたがる置き換えや移行（API の差し替え、文書の用語の統一）。
• 似た編集を何回も続けるとき。
• commit と PR の順番を決めるとき。

やること:

• 各単位を、既知の良い状態 → 1 つの変更 → 検査 → 次、の括りにする。始める前に最新の幹（main や develop）へ rebase し、検査が本当の基線と比べるようにする。
• スクリプトで編集していても、単位ごとの検査は省かない。
• 証明になる順に積む。基本の形は、落ちる試験の commit を先に、その上に修正。ほかに、作り替えの前の削除、手当ての前の基線の記録、機能の前の土台。各 commit は単独で成り立つ。

使わないとき: 1 回で終わる小さな変更で、分けても検査の回数が増えるだけの場合。

確かめる例: commit の列を順に読むと、落ちる試験 → 修正、削除 → 追加のように主張になっている。どの commit でも検査が通る。