並行Git作業で他人の変更を巻き込まない

しろまえ殿は、複数人が同じリポジトリを触る現場で、コミット（変更履歴への確定保存）が意図したファイルだけになるとは限らないことを確認した。 並行作業では、変更の境界をコマンド任せにしないことが結論だ。

ある担当者が自分のファイルを追加した。 その直後、別の担当者が別ファイルを追加した。 ここで通常のcommitを実行すると、共有されているインデックス（次のコミット候補を置く場所）全体が対象になる。 自分の追加分だけだと思い込むと、別作業の変更まで同じ履歴へ入る。

さらに、commitにパスを指定すれば安全だと思いがちだ。 しかし指定方法によっては、ステージ済みの内容ではなく、作業ツリー（現在のファイル一式）の内容を使う。 同じファイルを別担当者が編集中なら、未完成の差分を拾う余地が残る。

しろまえ殿は、まず着手時に作業ツリーを確認した。 担当外の差分があれば、そのまま進めず記録した。 次に、追加対象をファイル単位で明示した。 git add . のような全体指定は避けた。

コミット直前には、ステージ差分を表示した。 ファイル名だけでなく、内容も見る。 意図しない差分が混ざっていれば、コミットを止める。

たとえば、共有の回覧板に自分の一枚だけを綴じるつもりが、隣の人の書類まで一緒に製本してしまう状況に近い。 綴じる前にページを数えるだけで、事故はかなり減る。

コミット後も確認を続けた。 履歴に含まれるファイルを表示し、担当対象と一致するかを照合した。 コミットの実体が存在することと、現在の先頭履歴へ到達していることも確認した。

もし巻き込みを見つけても、履歴を独断で書き換えない。 共有リポジトリでは、復旧操作そのものが別の変更を壊すことがある。 まず混入したファイルと時系列を報告し、影響範囲を確定してから直す。

しろまえ殿が得た教訓は、Gitの操作を覚えることだけではない。 誰が何を触るかを先に宣言し、追加・確認・確定を一息で行う。 共有作業では、この小さな習慣が大きな巻き戻しを防ぐ。