7
Bazaarは多くの異なる共同作業の方法を支援します。
8
このことはあるワークフローで始めて状況が変われば別のワークフローを\
10
"唯一の正しい方法"は存在しませんし今後も現れることはりません。
11
このセクションではBazaarによってサポートされる人気のあるいくつかの\
14
これらのワークフローはBazaarの使い方の *一部* であることを念頭にお願いします。
15
ここに記載されていないワークフローを利用したいのであれば、\
16
下記に記載されているアイディアを足場にします。
21
ソフトウェアを開発する、ドキュメントを編集するもしくは設定ファイルを\
22
変更するのであれ、簡単に使えるVCSは手助けになります。
23
投稿者が1人であるプロジェクトを複数管理するために\
24
単独のユーザーはこのワークフローを効率的に利用できます。
26
.. image:: images/workflows_single.png
28
まったくバージョン管理を使わない場合と比べたこのワークフローの利点は次のとおりです:
34
このワークフローに適切なBazaarの主要な機能は管理作業が少ない\
35
(サーバーのセットアップは不要)ことと簡単に利用できることです。
41
時に2人で変更を共有して共同作業をする必要があります。
42
これは一般的に *ソロ* のワークフロー (上記を参照) もしくは\
43
チーム指向のワークフロー(下記を参照)として始まります。
44
ある時点で、2人目の人が最初の人が行った内容(履歴も含む)を含む\
46
適切なときにマージして変更内容を交換することで並行して作業できます。
48
.. image:: images/workflows_peer.png
53
* それぞれのテキストファイルのそれぞれの行は変更した人、\
54
時間と理由を含む特定の変更と結びつけられています。
56
このワークフローを採用する場合、BazaarはCVSとSubversionに対して
60
* インテリジェントなマージ機能により複数回のマージ作業が苦痛では
67
*lock-step* としても知られますが、これはCVSとSubversionによって\
68
推奨/強制されるワークフローと本質的に同じです。
69
すべての開発者が同じブランチに取り組みます。
70
最新の内容をチェックアウトするために ``bzr update`` を実行し、\
71
変更内容を中心位置にコミットするために ``bzr commit`` を実行します。
73
.. image:: images/workflows_centralized.png
75
このワークフローを導入するのであればSubversionとCVSも簡単なのでよい選択肢です。
76
Bazaarはこのワークフローも直接サポートしていて、CVSとSubversionを上回る利点を\
84
---------------------------
86
このワークフローは、開発者が ``commit --local`` もしくはチェックアウトをunbind\
87
して一連の変更を行うこと以外は、 *集中型* モデルと基本的に同じです。
88
こういった一連の変更が完了するとき、開発者は作業内容を共用のメインラインに\
91
.. image:: images/workflows_localcommit.png
95
* 旅行の間にネットに接続していないなどのオフラインで作業できます
96
* 誰かの作業を妨げる良くないコミットをする機会が少なくなります
98
SubversionとCVSはこのモデルをサポートしません。
99
他の分散型VCSツールはこれをサポートしますが、Bazaarよりも直接的ではありません。
103
-----------------------------
105
このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、\
106
加えてメインブランチにコミットする権限があります。
107
開発者は個人のブランチに取り組み、準備ができたらそれをメインラインに\
110
.. image:: images/workflows_shared.png
112
*ローカルコミットつきの集中型* を越える利点は次のとおりです:
114
* 作業内容の編成が簡単になる - それぞれのブランチで個別の変更を開発できます。
115
* 開発者は共同作業に取り組むときに別の人の個人ブランチをマージできます。
117
SubversionとCVSはこのモデルをサポートしません。\
119
Bazaarの多くの機能は、簡単な利用、共用レポジトリ、統合されたマージ機能と\
120
リッチなメタデータ(ディレクトリのリネームの追跡を含む)を\
124
-----------------------------
126
このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、\
127
それに加えてメインのブランチに対してリードオンリーのアクセス権限を持ちます。
128
1人の開発者(ゲートキーパー)はメインのブランチにコミットする権限を持ちます。
129
1人の開発者が彼らの作業をマージしたい場合、ゲートキーパーに\
131
ゲートキーパーはコードのレビューを行い、必須の基準を満たすのであれば\
134
.. image:: images/workflows_gatekeeper.png
136
*共用のメインラインによる分散型* に対する利点は次のとおりです:
138
* 常にコードはメインラインに入る前にレビューされます。
139
* 変更をメインラインに組み込むときに厳格なコントロールができます
141
Bundle Buggyと呼ばれるBazaarのコンパニオンツールはどんな変更が\
142
レビュー待ちになっているのか、その変更のステータスとレビューアの\
147
-------------------------------
149
このワークフローにおいて、それぞれの開発者は独自のブランチを持つのに加えて、\
150
メインストリームにリードオンリーのアクセス権限を持ちます。
151
ソフトウエアのゲートキーパーはメインのブランチにコミットする権限を持ちます。
152
開発者が作業内容をマージしたいとき、開発者は別の人にレビューを頼みます。
153
レビューに合格したら、チームの方針によって、オリジナルの著者もしくは
154
レビューワがゲートキーパーソフトウェアにマージするように頼み、
155
ゲートキーパーソフトウェアはマージし、コンパイルし、テストスィートを実行します。コードがパスする場合のみ、メインラインにマージされます。
157
注: 代替として、レビューのステップをスキップして著者は変更を自動化された\
159
(これはコードのレビューを別のステップとしてではなくジャストインタイムの\
160
レビューを効果的に推進するペアプログラミングといった習慣を利用している\
163
.. image:: images/workflows_pqm.png
165
*人間のゲートキーパーによる分散型* に対する利点は次のとおりです:
167
* コードはメインラインに入る前に常にテストされます
171
BazaarのコンパニオンツールであるPatch Queue Manager (PQM)
172
は自動化ゲートキーパーの機能を提供します。
176
-----------------------
178
上記のそれぞれのワークフローを実施する方法を詳しく知りたいのであれば、\
179
このマニュアルの3章から6章までを参照してください。最初に、2章で、\
180
インストール方法、一般的な使い方の手引きと設定方法に関するティップス\
added
removed
doc/ja/user-guide/bazaar_workflows.txt
