← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/ja/user-guide/bazaar_workflows.txt

  • Committer: Alexander Belchenko
  • Date: 2006-07-30 16:43:12 UTC
  • mto: (1711.2.111 jam-integration)
  • mto: This revision was merged to the branch mainline in revision 1906.
  • Revision ID: bialix@ukr.net-20060730164312-b025fd3ff0cee59e
rename  gpl.txt => COPYING.txt

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ja/user-guide/bazaar_workflows.txt
1
 
ワークフロー
2
 
=============
3
 
 
4
 
Bazaarはただのツール
5
 
---------------------
6
 
 
7
 
Bazaarは多くの異なる共同作業の方法を支援します。
8
 
このことはあるワークフローで始めて状況が変われば別のワークフローを\
9
 
採用できることを意味します。
10
 
"唯一の正しい方法"は存在しませんし今後も現れることはりません。
11
 
このセクションではBazaarによってサポートされる人気のあるいくつかの\
12
 
ワークフローの手短な概要を提供します。
13
 
 
14
 
これらのワークフローはBazaarの使い方の *一部* であることを念頭にお願いします。
15
 
ここに記載されていないワークフローを利用したいのであれば、\
16
 
下記に記載されているアイディアを足場にします。
17
 
 
18
 
ソロ
19
 
----
20
 
 
21
 
ソフトウェアを開発する、ドキュメントを編集するもしくは設定ファイルを\
22
 
変更するのであれ、簡単に使えるVCSは手助けになります。
23
 
投稿者が1人であるプロジェクトを複数管理するために\
24
 
単独のユーザーはこのワークフローを効率的に利用できます。
25
 
 
26
 
.. image:: images/workflows_single.png
27
 
 
28
 
まったくバージョン管理を使わない場合と比べたこのワークフローの利点は次のとおりです:
29
 
 
30
 
 * 古いバージョンのバックアップ
31
 
 * 前の状態へのロールバック
32
 
 * 履歴の追跡
33
 
 
34
 
このワークフローに適切なBazaarの主要な機能は管理作業が少ない\
35
 
(サーバーのセットアップは不要)ことと簡単に利用できることです。
36
 
 
37
 
 
38
 
パートナー
39
 
-----------
40
 
 
41
 
時に2人で変更を共有して共同作業をする必要があります。
42
 
これは一般的に *ソロ* のワークフロー (上記を参照) もしくは\
43
 
チーム指向のワークフロー(下記を参照)として始まります。
44
 
ある時点で、2人目の人が最初の人が行った内容(履歴も含む)を含む\
45
 
ブランチを作ります。
46
 
適切なときにマージして変更内容を交換することで並行して作業できます。
47
 
 
48
 
.. image:: images/workflows_peer.png
49
 
 
50
 
*ソロ* を上回る利点は次のとおりです:
51
 
 
52
 
 * 変更の共有が簡単
53
 
 * それぞれのテキストファイルのそれぞれの行は変更した人、\
54
 
   時間と理由を含む特定の変更と結びつけられています。
55
 
 
56
 
このワークフローを採用する場合、BazaarはCVSとSubversionに対して
57
 
次のような利点があります:
58
 
 
59
 
 * サーバーのセットアップが不要
60
 
 * インテリジェントなマージ機能により複数回のマージ作業が苦痛では
61
 
   なくなります。
62
 
 
63
 
 
64
 
集中型
65
 
-------
66
 
 
67
 
*lock-step* としても知られますが、これはCVSとSubversionによって\
68
 
推奨/強制されるワークフローと本質的に同じです。
69
 
すべての開発者が同じブランチに取り組みます。
70
 
最新の内容をチェックアウトするために ``bzr update`` を実行し、\
71
 
変更内容を中心位置にコミットするために ``bzr commit`` を実行します。
72
 
 
73
 
.. image:: images/workflows_centralized.png
74
 
 
75
 
このワークフローを導入するのであればSubversionとCVSも簡単なのでよい選択肢です。
76
 
Bazaarはこのワークフローも直接サポートしていて、CVSとSubversionを上回る利点を\
77
 
いくつかもちます:
78
 
 
79
 
 * よりよいブランチとマージ
80
 
 * よりよいリネームのサポート
81
 
 
82
 
 
83
 
ローカルなコミットで集中型
84
 
---------------------------
85
 
 
86
 
このワークフローは、開発者が ``commit --local`` もしくはチェックアウトをunbind\
87
 
して一連の変更を行うこと以外は、 *集中型* モデルと基本的に同じです。
88
 
こういった一連の変更が完了するとき、開発者は作業内容を共用のメインラインに\
89
 
コミットします。
90
 
 
91
 
.. image:: images/workflows_localcommit.png
92
 
 
93
 
*集中型* を越える利点:
94
 
 
95
 
 * 旅行の間にネットに接続していないなどのオフラインで作業できます
96
 
 * 誰かの作業を妨げる良くないコミットをする機会が少なくなります
97
 
 
98
 
SubversionとCVSはこのモデルをサポートしません。
99
 
他の分散型VCSツールはこれをサポートしますが、Bazaarよりも直接的ではありません。
100
 
 
101
 
 
102
 
共用のメインラインで分散型
103
 
-----------------------------
104
 
 
105
 
このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、\
106
 
加えてメインブランチにコミットする権限があります。
107
 
開発者は個人のブランチに取り組み、準備ができたらそれをメインラインに\
108
 
マージします。
109
 
 
110
 
.. image:: images/workflows_shared.png
111
 
 
112
 
*ローカルコミットつきの集中型* を越える利点は次のとおりです:
113
 
 
114
 
 * 作業内容の編成が簡単になる - それぞれのブランチで個別の変更を開発できます。
115
 
 * 開発者は共同作業に取り組むときに別の人の個人ブランチをマージできます。
116
 
 
117
 
SubversionとCVSはこのモデルをサポートしません。\
118
 
他の分散型VCSツールはサポートします。
119
 
Bazaarの多くの機能は、簡単な利用、共用レポジトリ、統合されたマージ機能と\
120
 
リッチなメタデータ(ディレクトリのリネームの追跡を含む)を\
121
 
含めてこのワークフローに有効です。
122
 
 
123
 
人間のゲートキーパーで分散型
124
 
-----------------------------
125
 
 
126
 
このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、\
127
 
それに加えてメインのブランチに対してリードオンリーのアクセス権限を持ちます。
128
 
1人の開発者(ゲートキーパー)はメインのブランチにコミットする権限を持ちます。
129
 
1人の開発者が彼らの作業をマージしたい場合、ゲートキーパーに\
130
 
マージしてくれるように頼みます。
131
 
ゲートキーパーはコードのレビューを行い、必須の基準を満たすのであれば\
132
 
作業内容をメインブランチにマージします。
133
 
 
134
 
.. image:: images/workflows_gatekeeper.png
135
 
 
136
 
*共用のメインラインによる分散型* に対する利点は次のとおりです:
137
 
 
138
 
 * 常にコードはメインラインに入る前にレビューされます。
139
 
 * 変更をメインラインに組み込むときに厳格なコントロールができます
140
 
 
141
 
Bundle Buggyと呼ばれるBazaarのコンパニオンツールはどんな変更が\
142
 
レビュー待ちになっているのか、その変更のステータスとレビューアの\
143
 
コメントを追跡するのにとても便利です。
144
 
 
145
 
 
146
 
自動的なゲートキーパーで分散型
147
 
-------------------------------
148
 
 
149
 
このワークフローにおいて、それぞれの開発者は独自のブランチを持つのに加えて、\
150
 
メインストリームにリードオンリーのアクセス権限を持ちます。
151
 
ソフトウエアのゲートキーパーはメインのブランチにコミットする権限を持ちます。
152
 
開発者が作業内容をマージしたいとき、開発者は別の人にレビューを頼みます。
153
 
レビューに合格したら、チームの方針によって、オリジナルの著者もしくは
154
 
レビューワがゲートキーパーソフトウェアにマージするように頼み、
155
 
ゲートキーパーソフトウェアはマージし、コンパイルし、テストスィートを実行します。コードがパスする場合のみ、メインラインにマージされます。
156
 
 
157
 
注: 代替として、レビューのステップをスキップして著者は変更を自動化された\
158
 
ゲートキーパーに投稿できます。
159
 
(これはコードのレビューを別のステップとしてではなくジャストインタイムの\
160
 
レビューを効果的に推進するペアプログラミングといった習慣を利用している\
161
 
ときにとりわけ適切です。)
162
 
 
163
 
.. image:: images/workflows_pqm.png
164
 
 
165
 
*人間のゲートキーパーによる分散型* に対する利点は次のとおりです:
166
 
 
167
 
 * コードはメインラインに入る前に常にテストされます
168
 
   (メインラインの完全性が高まります)
169
 
 * チームの規模の成長に対応できます
170
 
 
171
 
BazaarのコンパニオンツールであるPatch Queue Manager (PQM)
172
 
は自動化ゲートキーパーの機能を提供します。
173
 
 
174
 
 
175
 
ワークフローを実施する
176
 
-----------------------
177
 
 
178
 
上記のそれぞれのワークフローを実施する方法を詳しく知りたいのであれば、\
179
 
このマニュアルの3章から6章までを参照してください。最初に、2章で、\
180
 
インストール方法、一般的な使い方の手引きと設定方法に関するティップス\
181
 
が説明されています。