5
-----------------------
7
Bazaarは多くの点で他のVCSに似ていますが、最初見たときに必ずしも明らかではない大きな違いがいくつかあります。
8
このセクションでは Bazaarを"grok"するため、すなわち深く理解するために、
9
ユーザーが知る必要のあるいくつかの内容の説明を試みます。
11
注: Bazaarを使うためにこのセクションを十分に理解する必要はありません。
12
このセクションをさっと読んで後で戻るとよいでしょう。
15
------------------------
17
ブランチのメインラインのすべてのリビジョンは単純に増加する整数を持ちます(最初のコミットは1、10番目のコミットは10などです)。
18
これによって "私のブランチから10番目のリビジョンを獲得する"、もしくは "リビジョン3050で修正した" という言い方が自然になります。
20
ブランチにマージされるリビジョンに関しては、ドットつきのバージョンが使われます(たとえば、3112.1.5)。
21
ドットつきのリビジョン番号は3つの番号を持ちます [#]_.
22
最初の番号はメインのリビジョンの変更の由来を示します。
24
同じリビジョンから多くのブランチが由来することがあり得るので、それらのブランチはユニークな番号を取得します。
25
3番目の番号はブランチの開始以降のリビジョン番号です。
26
たとえば、3112.1.5はリビジョン3112からの最初のブランチで、そのブランチ上の5番目のリビジョンです。
28
.. [#] バージョン1.2以前のbzrでは少し異なるアルゴリズムが使われていました。
29
いくつかの入れ子のブランチはよりシンプルな3つの番号システムではなく追加の番号(たとえば1.1.1.1.1)を取得します。
32
-------------------------------
34
多くの変更が一連のコミットで構成される状況で複数の開発者が変更を投稿するプロジェクトを想像してください。
35
具体例を示すために、次の事例を考えてみましょう:
37
* プロジェクトのトランクのチップはリビジョン100です。
38
* Maryは機能Xを配信するために3つの変更を行う
39
* Billは機能Yを配信するために4つの変更を行う
41
開発者が並行して作業して伝統的な集中型のVCSのアプローチを利用する場合、
42
大抵の場合プロジェクトの履歴は次のようにMaryの変更とBillの変更が交互に混ざります::
44
107: Add documentation for Y
45
106: Fix bug found in testing Y
46
105: Fix bug found in testing X
48
103: Add documentation for X
49
102: Add code and tests for X
53
多くのチームはこのアプローチを利用します。彼らのツールではブランチの作成とマージが難しいからです。
54
結果として、開発者はトランクからの更新とコミットを頻繁に行い、すべてのコミットを通してそれを広げることで統合の苦痛を最小化します。
55
望むのであれば、このようにBazaarを使うことができます。
56
Bazaarは考慮すべき別の方法を提供します。
58
分散型のVCSツールによって推奨される代替のアプローチは機能ブランチを作り、準備ができたらそれらを統合することです。
59
この場合、Maryの機能ブランチは次のようになります::
61
103: Fix bug found in testing X
62
102: Add documentation for X
63
101: Add code and tests for X
66
そしてBillのものは次のようになります::
68
104: Add documentation for Y
69
103: Fix bug found in testing Y
74
機能が独立していてリニアな履歴を維持したいのであれば、変更はバッチでトランクにpushされます。
75
(技術的には、これを行う方法は無数にありますがこの検討内容の範囲を超えます。)
78
107: Fix bug found in testing X
79
106: Add documentation for X
80
105: Add code and tests for X
81
104: Add documentation for Y
82
103: Fix bug found in testing Y
87
これを実現するために少し努力が必要な一方で、リビジョンをランダムに織り交ぜるよりもいくつかの利点があります。
88
よりベターですが、non-linearな履歴を形成してブランチは一緒にマージできます。
92
100.2.3: Fix bug found in testing X
93
100.2.2: Add documentation for X
94
100.2.1: Add code and tests for X
96
100.1.4: Add documentation for Y
97
100.1.3: Fix bug found in testing Y
98
100.1.2: Add code for Y
99
100.1.1: Add tests for Y
106
100.2.2: Add documentation
107
100.2.1: Add code and tests
109
100.1.4: Add documentation
110
100.1.3: Fix bug found in testing
115
多くの理由からこれはよいものと考えられます:
117
* プロジェクトの履歴を理解するのが楽になります。
118
関連した変更はクラスターを形成し明確に区切られます。
120
* ブランチのメインライン上のコミットだけを見るために履歴を簡単に折りたたむことができます。
121
(このレベルでは興味のない膨大な数のコミットの代わりに)
122
このようなトランクの履歴を閲覧するとき、高いレベルのコミットだけ見えます。
124
* 必要であれば、より簡単に機能の変更を取り消します
126
* 継続的インテグレーション(Continuous integration: CI)ツールは
127
マージをメインラインにコミットするためにすべてのテストが合格することを保証するために使われます。
128
(多くの場合、すべての単独のコミットの後でCIツールの引き金を引くのは適切ではありません。
129
テストの中には開発の間に失敗するものがあるからです。
130
実際、テストファーストの追加 - テスト駆動開発(TDD)のスタイル - によってこれが保証されます！)
134
*ブランチを利用してあなたの作業内容を編成する*
138
*順序つきの番号と階層によって履歴を追跡するのが楽になる*
141
それぞれのブランチは履歴の独自のビューを持つ
142
---------------------------------------------
144
上述のように、Bazaarは次の内容を区別します:
146
* メインラインのリビジョン、すなわちブランチにコミットしたもの
148
* マージしたリビジョン、マージをコミットすることで祖先として追加されるもの
150
それぞれのブランチは効率的に履歴の独自ビューを持ち、すなわち、
151
異なるブランチは同じリビジョンに異なる"ローカルな"リビジョン番号を与えます。
153
マージされたリビジョンは常にドットつきのリビジョン番号を入手するのに対して
154
メインラインのリビジョンは常に単独の数字のリビジョン番号が割り当てられます。
156
上記の例を拡張するためには、Maryが変更を完了させた後でプロジェクトのトランクにマージした後に
157
Maryのブランチのリビジョンの履歴は次のようになります::
160
100.2.1: Merge feature Y
161
100.1.4: Add documentation
162
100.1.3: Fix bug found in testing
165
103: Fix bug found in testing X
166
102: Add documentation for X
167
101: Add code and tests for X
170
繰り返しますが、Maryはこの変更を開発するためにステップを見るために彼女の履歴のトップレベルを調べることが簡単になります。
171
この文脈では、トランクのマージ(とそれを行うことによる衝突の解消)はこのブランチの履歴に関しては単なる1つのステップです。
173
Bazaarは履歴を変更するのでなければグローバルなリビジョン識別子を変更するのでもないことを覚えておくのは大事です。
174
本当に望むのであれば常に後者を使用できます。
175
実際、ブランチのURLをコンテクストとして提供する *限り* コミュニケーションをするときに特定のリビジョン番号を使うことができます。
176
(多くのBazaarのプロジェクトでは、開発者はブランチURLなしでリビジョン番号を交換するとき中心のトランクのブランチをほのめかします)
178
マージはブランチのリビジョン番号を変更しません。それらはローカルのリビジョン番号を新しくマージしたリビジョンに割り当てるからです。
179
Bazaarがブランチのリビジョン番号を変更する唯一のときはあなたが明示的に別のブランチをミラーリングするように頼むときです。
181
注: リビジョンは安定した方法で番号づけされます: 2つのブランチがメインラインで同じリビジョン番号を持つとき、
182
そのリビジョンの祖先のすべてのリビジョンは同じリビジョン番号を持ちます。
183
たとえば、AliceとBobのブランチがリビジョン10に一致するのであれば、それらはそれ以前のすべてのリビジョンで一致します。
188
一般的に、前に示されたアドバイスに従うのであれば - ブランチの中で作業し、\
190
Bazaarが一般的にあなたが期待することを行うことがわかります。
192
次の章では、Bazaarを利用したさまざまな方法: もっとも単純なプロジェクト、個人プロジェクトなどを試します。
added
removed
doc/ja/user-guide/zen.txt
