動機

多くの分散型のシナリオでは、開発者にとってURLを公開することでタスクブランチを共有することが常に現実的であるとは限りません。 たとえば、開発者が在宅で一晩中作業をする場合、ゲートキーパーが別のタイムゾーンでレビューしてマージしたいときに開発者はタスクブランチに十分にアクセスできません。

Bazaarは手助けする巧妙な機能: マージディレクティブ を提供します。

マージのディレクティブを理解する

マージディレクティブを”ミニブランチ” - ブランチが作成された後の成長部分 - として考えることができます。 これは変更点を記したソフトウェアパッチですが、追加情報として中間コミット、リネームとデジタル署名のようなメタデータがつきます。

別の実用的なメタファはパケットケーキ: レシピと必要な材料を持ったマージディレクティブです。 具体的にいえば、材料とはブランチ上で加えられた全ての変更のメタデータで、レシピとはそれらの変更点をどうやってマージするかで、 merge コマンドが共通の祖先を選ぶのに利用する情報です。

それらをどのように考えるのであれ、マージディレクティブはよいものです。 これらは簡単に作れて、メールに添付して送信するのに最適で、受け取った後でブランチと同じように処理できます。

マージディレクティブを作る

マージディレクトリを作りオプションとして送信するためには、 send コマンドを使います。

デフォルトでは、 send はマージディレクティブを ブランチのための “投稿アドレス” 、 通常はリード開発者もしくは開発メーリングリストにEメールを送信します。 オプションなしの send はマージディレクティブを作り、Eメールツールを作動させて添付し、少しの説明文を追加するための準備をします。 (この設定方法の詳細に関してはオンラインヘルプの send と リファレンスマニュアルの 構成設定 を参照)

大抵のプロジェクトではパッチ付きのメールに説明文を追加し、パッチの理由と内容を説明します。 これによってレビューワは行単位の差分に入る前にいくらかの事情を理解できます。

代わりに、 --output (or -o) オプションが渡されると、 send はマージディレクティブをファイルに書くので、あなた自身にメールを送り、 それを検査し、後の使用のために保存できます。 - の出力ファイルが渡されると、ディレクティブはstdoutに書き込まれます。例です:

cd X-fix-123
bzr send -o ../fix-123.patch

マージのディレクティブを適用する

merge と pull コマンドを使うことでマージディレクティブはブランチと同じ方法で適用できます

これらはBazaarを使わない上流のプロジェクトとコミュニケーションをするときにも便利です。 とりわけ、マージディレクティブ内の変更全体のプレビューは無地のソフトウェアパッチのようになるので、たとえば彼らは patch -p0 を使用してそれらを適用できます。