~bzr-pqm/bzr/bzr.dev : contents of doc/ja/user-guide/zen.txt at revision 4964

~bzr-pqm/bzr/bzr.dev : (revision 4964)

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