選択的なファイルのコミット

以前に、ツリー内の全変更を一度に commit する方法を学習しました。(変更物のチェックインを参照)

さらに、"クリーン"チェンジセットを作る重要性に関しても少し触れました (commit をうまく使う -- クリーンチェンジセットの考えを参照).

本章では、非常に限定的ですが, よくある状況で使える小さなトリックをお見せします.

素早い解決の問題

大きなプロジェクトツリーを持っており、ある複雑な変更を加えている最中だとしましょう. 沢山のファイルを修正しましたが、まだ触れていないものも沢山あります.

突然、手をつけてないファイルのひとつの, ささいなバグを見つけたとします.

本当にしたいことは以下のことです:

1) 作業を止めてそのささいなバグを修正する.

2) そのささいなバグフィックスを commit する.

3) 複雑な変更の作業に戻る.

いかにして、これを行うことができるのでしょう.

素早い解決の問題についての, 力任せの解法

その問題についての, 簡単な"力任せ"の解法があります.

単純に:

最新のリビジョンのコピーをチェックアウトする. 言い換えれば、変更点の無い, 第二のプロジェクトを作ります。

新しいツリーで, 問題のささいなバグを直し, commit する. これで問題のバグの修正のみについてのクリーンな変更をコミットできました.

update または replay を使用して, 元のツリーを更新する. 作業中のツリーに, 問題のささいなバグ修正が加わります.

これはうまく行くのですが, 少々ぎこちないこともありえます. ささいなバグを直すのに, 別のプロジェクトツリーを開始することが, 本当に必要ですか?

ぎこちないことでも, やる価値があることもあります. 例えば, あなたのプロジェクトのポリシーでは, 全てのコミットの前にテストを実行しなければならないかもしれません. その場合, 確かに, 別ツリーが必要です.

ぎこちないことを避けられないこともあります. 例えば, ささいなバグフィックスが, すでに大きく修正されたファイルへの変更を含む場合です. このときは, 力任せが最も単純なやりかたかもしれません (しかし, tla undo --help と tla redo --help も参照して下さい).

しかし、もっと簡単な方法が使えることもあります:

素早い解決の問題についての, commit -- による解法

結局のところ, commit で, わずかのファイルにのみ行なわれた変更だけをコミットできます.

file-a.c と file-b.c のみの変更ならば, ログメッセージを準備した後に, これらのファイルのみを commit することができます:

        % tla commit -- file-a.c file-b.c

注意すべきことは, この方法でコミットするファイルは新規のファイルであってはならないということです. さらに, ファイルが改名された場合でも, この commit では, これらのファイル内の修正のみが記録され, 改名は記録されません.

素早い解決の問題 -- やり方は一通りではない

以上で, 素早い解決の問題への, 新しいプロジェクトツリー全体をチェックアウトするという"力任せ"の解法を考えました.

他の 2つのコマンド, tla undo と tla redo は, とある利点のある, 別の"力任せ"の解法を提供します. これらの説明は後の章にあります.