7
開発をするために分散型のワークフローを利用する際の主要な違いは\
8
メインのローカルブランチは変更を行う場所ではないことです。
9
代わりに、中心ブランチのそのままのコピーとして保存されます。
10
すなわち、これは *ミラーブランチ* です。
12
ミラーブランチを作るためには、共用リポジトリ(まだなければ)を作り\
13
ミラーを作るために ``branch`` コマンド(もしくは ``checkout``)を使います。
18
bzr branch sftp://centralhost/srv/bzr/PROJECT/trunk
23
それぞれの新しい機能もしくは修正は独自のブランチの中で開発されます。
24
これらのブランチは *機能ブランチ* もしくは *タスクブランチ* として言及されます -
25
用語はお互いに置き換えて使うことができます。
27
タスクブランチを作るためには、ミラーブランチに対して ``branch`` コマンドを使います。
30
bzr branch trunk fix-123
36
1. 並行して複数の変更に取り組むことができます
38
3. 複数の人々は準備ができるまでpeer-to-peerモードでブランチに取り組むことができます
40
とりわけ、変更が他のものより料理するのに時間がかかるのであれば、レビューを求めたり、
42
中心ブランチにマージする前に個別のブランチで十分な品質の作業を完了させることで、
43
中心ブランチの品質と安定性は以前よりも高い水準を維持します。
46
---------------------------------
48
これを行うためには ``pull`` コマンドを使います::
54
-----------------------------------------
56
これを行うためには ``merge`` コマンドを使います::
60
(resolve any conflicts)
61
bzr commit -m "merged trunk"
64
---------------------------
66
異なる分散型のワークフローの方針は変わります、
67
すべての開発者がメイントランクにコミットする権限を持つ最もシンプルな\
75
(resolve any conflicts)
76
bzr commit -m "Fixed bug #123"
83
(resolve any conflicts)
84
bzr commit -m "Fixed bug #123"
88
--------------------------------
90
集中型ワークフローの副作用の1つは変更がITオペレーションの一部として\
91
バックアップされる中心位置にしょっちゅうコミットされることです。
92
タスクブランチを開発するとき、作業内容を中心位置に公開することは\
93
バックアップになるのでよい考えです(しかし共用位置であることは必須ではありません)。
94
この目的のためだけにローカルのタスクブランチをバックアップサーバー上で\
95
確立されたリモートブランチにバインドするとよいかもしれません。
added
removed
doc/ja/user-guide/organizing_branches.txt
