ミラーブランチ

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

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

bzr init-repo PROJECT
cd PROJECT
bzr branch sftp://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オペレーションの一部としてバックアップされる中心位置にしょっちゅうコミットされることです。 タスクブランチを開発するとき、作業内容を中心位置に公開することはバックアップになるのでよい考えです(しかし共用位置であることは必須ではありません)。 この目的のためだけにローカルのタスクブランチをバックアップサーバー上で確立されたリモートブランチにバインドするとよいかもしれません。