7
多くの分散型のシナリオでは、開発者にとってURLを公開することでタスクブランチを\
8
共有することが常に現実的であるとは限りません。
9
たとえば、開発者が在宅で一晩中作業をする場合、ゲートキーパーが別のタイムゾーンで\
10
レビューしてマージしたいときに開発者はタスクブランチに十分にアクセスできません。
12
Bazaarは手助けする巧妙な機能: *マージディレクティブ* を提供します。
15
---------------------------------
17
マージディレクティブを"ミニブランチ" - ブランチが作成された後の成長部分 -
19
これは変更点を記したソフトウェアパッチですが、追加情報として中間コミット、\
20
リネームとデジタル署名のようなメタデータがつきます。
22
別の実用的なメタファはパケットケーキ: レシピと必要な材料を持った\
24
具体的にいえば、材料とはブランチ上で加えられた全ての変更のメタデータで、\
25
レシピとはそれらの変更点をどうやってマージするかで、 ``merge`` コマンドが\
28
それらをどのように考えるのであれ、マージディレクティブはよいものです。
29
これらは簡単に作れて、メールに添付して送信するのに最適で、受け取った後で\
33
-----------------------------
35
マージディレクトリを作りオプションとして送信するためには、 ``send`` コマンドを使います。
37
デフォルトでは、 ``send`` はマージディレクティブを ブランチのための "投稿アドレス" 、
38
通常はリード開発者もしくは開発メーリングリストにEメールを送信します。
39
オプションなしの ``send`` はマージディレクティブを作り、Eメールツールを作動させて添付し、\
41
(この設定方法の詳細に関してはオンラインヘルプの ``send`` と
42
リファレンスマニュアルの `構成設定 <../user-reference/bzr_man.html#configuration-settings>`_
45
大抵のプロジェクトではパッチ付きのメールに説明文を追加し、パッチの理由と内容を説明します。
46
これによってレビューワは行単位の差分に入る前にいくらかの事情を理解できます。
48
代わりに、 ``--output`` (or ``-o``) オプションが渡されると、 ``send``
49
はマージディレクティブをファイルに書くので、あなた自身にメールを送り、
50
それを検査し、後の使用のために保存できます。
51
``-`` の出力ファイルが渡されると、ディレクティブはstdoutに書き込まれます。例です::
54
bzr send -o ../fix-123.patch
58
---------------------------------
60
``merge`` と ``pull`` コマンドを使うことでマージディレクティブはブランチと同じ方法で\
63
これらはBazaarを使わない上流のプロジェクトとコミュニケーションをするときにも便利です。
64
とりわけ、マージディレクティブ内の変更全体のプレビューは無地のソフトウェアパッチの\
65
ようになるので、たとえば彼らは ``patch -p0`` を使用してそれらを適用できます。
added
removed
doc/ja/user-guide/sending_changes.txt
