コード開発プロジェクトにおけるソース管理システムの正しい利用法Beginner's Guide(3/4 ページ)

» 2008年04月11日 17時00分 公開
[Travis-Snoozy,Open Tech Press]
SourceForge.JP Magazine

 ソース管理システムの運用でよくみられるそのほかのミスは、複数の変更内容を1つのチェックインにまとめてしまうことである。チェックインの頻度を高くしておくとこの問題は回避できるが、仮に2つのコードがそれぞれ異なるバグを修正している場合、わずかコード2行分の変更に対応するチェックインであっても、それは複数の変更内容に対応することになる。つまり、論理上1つとみなせる変更を施すごとに1つのチェックインを実行していくべきなのだ。具体的な目安としてはバグを1つ修正するごとにチェックインも1回実行しておけばいい(ただし影響が広範囲に及んでいるバグについてはその修正完了までに複数のチェックインをすることもある)。同様に機能の追加についても、それが小規模なものであれば1つの機能をつけ加えるごとにチェックインを1つ設けるようにしておく。もっとも、中規模ないし大規模な機能追加をする場合は、ブランチ内の幾つかの論理ポイントにて複数のチェックインを設定する必要が生じることもあるだろうが、メインの開発エリアへのマージは機能が完成してから1度にまとめて実施すべきである。

 論理的な変更内容とチェックインを1対1に対応させておく最大の理由は、バグ発生時の対処に要する時間を短縮させるためである。つまり1つの変更ごとに1つのチェックインが設けられていると、品質保証(Quality Assurance)担当者はバグの混入した可能性の高い個所を早期に特定でき、チェックインのログを確認する際にも、個々のエントリごとに何が行われていたかを簡単に把握できるようになる。またメインラインに反映する変更を個々のチェックインごとに1つの完結した内容としておくと、生じてしまったバグを後から修正できなかった場合でも、問題を引き起こした変更以降のチェックインを取り消すという措置が比較的簡単に行えるはずである。そうではなく1つのチェックインが論理的に2つの変更に対応していると、そのチェックインの取り消しは必要以上の変更を取り消すことになり、無関係な機能を消し去ったりほかのバグフィックスを無効化してしまうことが懸念される。そしてこうした対応関係は、論理的な変更内容が2つである場合より1.5個分といった中途半端な対応をしている方が始末が悪いものである。

 darcsの場合、どの変更をチェックインするかをユーザーが明示的に指定する機能が設けられており、同一ファイルで複数の変更が行われている場合であってもこの機能は適用できる。1つの変更作業が終了して次の作業に取りかかる前に行うべきチェックインを忘れがちなユーザーにとって、この機能は特に役立つはずだ。

$ darcs record

hunk ./README 7

+

+Baz.

Shall I record this change? (1/?) [ynWsfqadjkc], or ? for help: y

hunk ./TODO 1

+foo!

Shall I record this change? (2/?) [ynWsfqadjkc], or ? for help: n

hunk ./TODO 23

+bar?

Shall I record this change? (3/?) [ynWsfqadjkc], or ? for help: y

What is the patch name? Bazbar

Do you want to add a long comment? [yn]n

Finished recording patch 'Bazbar'


 1つの変更内容ごとに1つのチェックインという原則を順守することで開発者自身が享受できるメリットとしては、各自の担当するソースツリーにて過剰な数の変更ファイルを保持しなくて済む点が挙げられる。わたし自身の経験上ビルドが破損するトップの理由は、行っておくべき変更内容のチェックインを開発者が実行し忘れていたか、あるいは逆に行うべきではない内容をチェックインしてしまったというものである。1つの変更内容ごとに1つのチェックインという原則を守るようにしておくと、ビルドの破損を気にすることなく、各自のソースツリーにて変更を施したすべてのファイルをチェックインできるようになる。

Copyright © 2010 OSDN Corporation, All Rights Reserved.

注目のテーマ