ブランチを編成する
===================

ミラーブランチ
----------------

開発をするために分散型のワークフローを利用する際の主要な違いは\
メインのローカルブランチは変更を行う場所ではないことです。
代わりに、中心ブランチのそのままのコピーとして保存されます。
すなわち、これは *ミラーブランチ* です。

ミラーブランチを作るためには、共用リポジトリ(まだなければ)を作り\
ミラーを作るために ``branch`` コマンド(もしくは ``checkout``)を使います。
例です::

  bzr init-repo PROJECT
  cd PROJECT
  bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/trunk

タスクのブランチ
-----------------

それぞれの新しい機能もしくは修正は独自のブランチの中で開発されます。
これらのブランチは *機能ブランチ* もしくは *タスクブランチ* として言及されます -
用語はお互いに置き換えて使うことができます。

タスクブランチを作るためには、ミラーブランチに対して  ``branch`` コマンドを使います。
例です::

  bzr branch trunk fix-123
  cd fix-123
  (hack, hack, hack)

この方法には数多くの利点があります:

 1. 並行して複数の変更に取り組むことができます
 2. 変更の間の交換が減ります
 3. 複数の人々は準備ができるまでpeer-to-peerモードでブランチに取り組むことができます

とりわけ、変更が他のものより料理するのに時間がかかるのであれば、レビューを求めたり、
フィードバックを適用することができます。
中心ブランチにマージする前に個別のブランチで十分な品質の作業を完了させることで、
中心ブランチの品質と安定性は以前よりも高い水準を維持します。

ミラーブランチをリフレッシュする
---------------------------------

これを行うためには ``pull`` コマンドを使います::

  cd trunk
  bzr pull

最新のトランクを機能ブランチにマージする
-----------------------------------------

これを行うためには ``merge`` コマンドを使います::

  cd fix-123
  bzr merge
  (resolve any conflicts)
  bzr commit -m "merged trunk"

機能をトランクにマージする
---------------------------

異なる分散型のワークフローの方針は変わります、
すべての開発者がメイントランクにコミットする権限を持つ最もシンプルな\
事例は下記のとおりです。

ミラーがチェックアウトなら::

  cd trunk
  bzr update
  bzr merge ../fix-123
  (resolve any conflicts)
  bzr commit -m "Fixed bug #123"

ミラーがブランチの場合::

  cd trunk
  bzr pull
  bzr merge ../fix-123
  (resolve any conflicts)
  bzr commit -m "Fixed bug #123"
  bzr push

タスクブランチをバックアップする
--------------------------------

集中型ワークフローの副作用の1つは変更がITオペレーションの一部として\
バックアップされる中心位置にしょっちゅうコミットされることです。
タスクブランチを開発するとき、作業内容を中心位置に公開することは\
バックアップになるのでよい考えです(しかし共用位置であることは必須ではありません)。
この目的のためだけにローカルのタスクブランチをバックアップサーバー上で\
確立されたリモートブランチにバインドするとよいかもしれません。