« back to all changes in this revision
Viewing changes to doc/ja/tutorials/centralized_workflow.txt
- browse files at revision 5875.1.1
- compare with another revision
- compare with revision 2131
- download diff
- download tarball
- view history from revision 5875.1.1
- Committer: INADA Naoki
- Date: 2011-05-18 06:01:08 UTC
- mto: This revision was merged to the branch mainline in revision 5894.
- Revision ID: songofacandy@gmail.com-20110518060108-86t2kffcrzu0nf6i
Update Japanese docs.
- files added:
- doc/ja/tutorials/licence.txt
- files modified:
- doc/ja/index.txt
added
removed
doc/ja/tutorials/centralized_workflow.txt
1
========================================
2
集中型ワークフローのチュートリアル
3
========================================
4
5
6
概要
7
====
8
9
この文書では、 Bazaar_ を使用することで実現可能なワークフローについて説明します。
10
つまり、分散バージョンコントロールシステムである Bazaar_ を、集中型のやり方で使用するためのワークフローです。
11
Bazaar_ は、非常にフレキシブルに設計されており、完全な分散型からほとんど集中型のワークフローまで、\
12
いくつかの異なるワークフローを受け入れることができます。
13
このワークフローは、初めてのユーザでも簡単に Bazaar_ を使いこなすことができ、\
14
分散型と集中型のオペレーションを組み合わせた業務にも対応できるようになっています。
15
16
基本的に、この文書はCVSやSubvresionのような集中型バージョンコントロールシステムの経験があるユーザ向けに書かれています。
17
これらの環境では、一般的に、コードベースをホストする単一の中央サーバが存在し、複数の人々がこのコードベース上で作業して、\
18
お互いの作業の同期をとることになります。
19
また、このワークフローは、一人の開発者が複数のマシーン上で作業をする場合にも適用できます。
20
21
.. _Bazaar: http://bazaar.canonical.com
22
23
24
初期セットアップ
25
================
26
27
Bazaar_ がうまく動くようにするための、まあまあ簡単なセットアップ手順があります。
28
29
ユーザのEメールの設定
30
---------------------
31
32
ユーザIDは各コミットに保存されます。これは正確だったり一意だったりする必要はありませんが、\
33
ログメッセージや注釈で使用されるため、何かしら実在する値を設定しておいた方がよいでしょう。
34
35
::
36
37
% bzr whoami "John Doe <jdoe@organization.com>"
38
39
40
ローカルリポジトリのセットアップ
41
--------------------------------
42
43
Bazaar_ のブランチは、通常は履歴のコピーを持っています。そのおかげで分散型での作業ができるわけです。
44
最適化の方法の一つとして、関連するブランチ同士の情報を統合して、\
45
新しいブランチを作るたびに履歴情報を丸ごとコピーしなくてもいいようにすることができます。
46
47
そのための一番いい方法は、 `共用リポジトリ`_ を作成することです。
48
一般に、 `共用リポジトリ`_ のサブディレクトリ内に複数のブランチがある場合、お互いの記憶領域を共有します。
49
ですので、ホームディレクトリに `共用リポジトリ`_ を作成するようにしましょう。
50
そうすれば、その下に作成したすべてのブランチは、履歴情報の領域を共有することになります。
51
52
::
53
54
% bzr init-repo --trees ~
55
56
57
リモートリポジトリのセットアップ
58
---------------------------------
59
60
作業用の領域とは別に、データを蓄積しておく領域が欲しいというのはよくあることです。
61
集中型のシステム(CVS/SVN)では、このようなワークフローが必要になります。
62
たいていは、これらは別々のマシーンに分けて配置されます。(そうでないこともあります。)
63
実際のところ、これは、特に職場ではとてもよい設定です。
64
蓄積されたデータはバックアップを確実にとることができ、開発者のマシーンに何かトラブルが起こっても\
65
コミットされたデータはけっして無くなりません。
66
67
それでは、プロジェクト内で共有する ``centralhost`` というマシーンを用意しましょう。
68
先ほども言いましたが、ディスクの使用量を節約するために、 `共用リポジトリ`_ を使用します。
69
70
::
71
72
% bzr init-repo --no-trees sftp://centralhost/srv/bzr/
73
74
この手順は、新しくcvsrootやSubversionのリポジトリを作るのと同じようなものだと考えることができます。
75
``--no-tree`` オプションの指定によって、ワーキングツリーを作らないようになります。
76
中央リポジトリ内のブランチを直接変更することは無いので、このオプションを指定しておくとよいでしょう。
77
78
79
既存のプロジェクトからの移行
80
=============================
81
82
リポジトリができましたので、プロジェクトの作成にかかりましょう。
83
たいていの場合、 Bazaar_ でバージョン管理したい作業中のコードがすでにあるはずです。
84
もし、そのコードがもともとソース管理されていたのであれば、履歴の情報を保ったまま Bazaar_ に\
85
変換する方法がたくさんあります。
86
しかしながら、それについてはここでは説明しません。詳しくは、 `Tracking Upstream`_ の\
87
"Converting and keeping history"セクションを見てください。
88
89
.. _Tracking Upstream: http://wiki.bazaar.canonical.com/TrackingUpstream
90
91
..
92
XXX: プロジェクトの変換について話をするための別の文書が必要なのですが、\
93
今ある中ではTrackingUpstreamが一番よい文書です。
94
95
96
Developer 1: 最初のリビジョンを作成する
97
-----------------------------------------
98
99
まず最初に、プロジェクトをホストするリモートリポジトリに、ブランチを作成したいと思います。
100
仮に、"sigil"というプロジェクトをバージョン管理しようとしているとしましょう。
101
102
::
103
104
% bzr init sftp://centralhost/srv/bzr/sigil
105
106
これは、CVSで言うところの"HEAD"ブランチ、Subversionなら"trunk"にあたるものだと考えてかまいません。
107
これを ``dev`` ブランチと呼ぶことにしましょう。
108
109
他のファイルとの競合を避けるために、ホームディレクトリのサブディレクトリ内で作業するのが私の好みです。
110
同じように、最終的にでき上がるすべてのブランチを格納できるプロジェクトディレクトリも欲しいですね。
111
::
112
113
% cd ~
114
% mkdir work
115
% cd work
116
% mkdir sigil
117
% cd sigil
118
% bzr checkout sftp://centralhost/srv/bzr/sigil dev
119
% cd dev
120
% cp -ar ~/sigil/* .
121
% bzr add
122
% bzr commit -m "Initial import of Sigil"
123
124
前のセクションでは、空のブランチ(``sigil`` ブランチ)を ``centralhost`` に作成して、\
125
それをクライアント端末にチェックアウトしたあと、元々あったプロジェクトのファイルを追加しています。
126
作業ディレクトリをセットアップするための方法はたくさんありますが、この方法を使うと機能追加用/バグフィックス用\
127
のブランチを使った作業が簡単にできます。
128
そして、複数のブランチをとてもうまく扱えるというのが、 Bazaar_ の長所の一つなのです。
129
130
この場合、リモートブランチのチェックアウトを持っているので、 ``~/work/sigil/dev/`` に対してコミットした内容が、\
131
ローカルと ``centralhost`` の両方に自動的に保存される訳です。
132
133
134
Developer N: プロジェクトの作業コピーを取得する
135
--------------------------------------------------
136
137
プロジェクトの作成に関するすべての作業は1人目の開発者がしてしまっているので、\
138
他のみんなは単にそのブランチをチェックアウトするだけです。
139
**ただし、** `ユーザのEメールの設定`_ **と** `ローカルリポジトリのセットアップ`_ **は見ておいてください。**
140
141
現在開発中のツリーのコピーを取得するためには::
142
143
% cd ~/work/sigil
144
% bzr checkout sftp://centralhost/srv/bzr/sigil dev
145
146
今、二人の人が ``sftp://centralhost/srv/bzr/sigil`` のチェックアウトを持っている状態なので、\
147
片方のチェックアウトが最新のものより古くなってしまうタイミングが出てきます。
148
コミットの時に、チェックアウトが古いければ Bazaar_ がエラーを返して、コミットは失敗します。
149
チェックアウトを最新にするには、よそで変更されたツリーに対して ``bzr update`` を使用します。
150
この時、もし同じファイルが変更されていれば、競合の解決が必要になるかもしれません。
151
152
153
別ブランチでの開発
154
====================
155
156
ここまでは、全員が同じブランチで作業して、変更をコミットしていました。
157
これはつまり、全員が適正かつ定期的にアップデートを行い、他の人の変更を取り扱う必要があると\
158
いうことです。
159
また、誰か一人が何かコードを壊すような変更をコミットして、それが同期されれば、\
160
全員が問題を抱えることになります。
161
162
たいていの場合、別のブランチ上で開発を行い、コードが安定してからメインのブランチに統合する\
163
というやり方の方が優れています。これが、CVSやSVNとの一番大きな違いです。
164
CVSやSVNも別ブランチでの開発はできますが、マージのアルゴリズムがかなり貧弱なので、\
165
ブランチ間できちんと同期がとれた状態に保つのは難しいことです。
166
Bazaar_ は、何がマージ済みかを記憶し、たとえファイルが変名されてる場合でもちゃんと変更を\
167
適用することができます。
168
169
170
新しいブランチを作成してそこで作業する
171
---------------------------------------
172
まだ変更が完了していない場合でも、他の人がその変更内容にアクセスできるようにしておきたいですよね。
173
そこで、 ``centralhost`` 上に新しい公開ブランチを作成して、それを手元に持ってくることにしましょう。
174
175
::
176
177
% cd ~/work/sigil
178
% bzr branch sftp://centralhost/srv/bzr/sigil \
179
sftp://centralhost/srv/bzr/sigil/doodle-fixes
180
% bzr checkout sftp://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
181
% cd doodle-fixes
182
183
これで、 ``doodle`` に必要な修正を当てるための場所ができました。
184
また、他の部分の修正をする人に邪魔されることもありません。
185
チェックアウトを持っているため、 ``~/work/sigil/doodle-fixes/`` に対してコミットした内容は\
186
``centralhost`` 上にも現れます。
187
[#nestedbranches]_ ``dev`` ブランチと同じように、このようなブランチ上で二人の開発者が共同で\
188
作業することもできます。
189
[#cbranch]_
190
191
.. [#nestedbranches] あるブランチのサブディレクトリに別のブランチがあるというのはおかしなこと\
192
に見えるかもしれませんが、これは何もおかしくありません。入れ子になったブランチは外側のブランチ\
193
から派生しているという点で、名前空間の階層と同じようなものだと考えることができます。
194
195
.. [#cbranch] たくさんの独立したブランチを使っている場合、毎回フルURLを入力するのは大変です。
196
このURLの入力を簡単にするために、ブランチエイリアスなどたくさんの方法を検討しています。
197
今のところ、 bzrtools_ プラグインが ``bzr cbranch`` コマンドを提供しています。
198
これは、ベースとなるブランチを指定して、新しく公開ブランチを作成し、そのチェックアウトを作成する\
199
ことを少ない入力でできるように設計されています。
200
``cbranch`` の使い方についてはこの文書の範囲外ですが、最後のコマンドについてはこんな感じです。:
201
202
::
203
204
% bzr cbranch dev my-feature-branch
205
206
.. _bzrtools: http://wiki.bazaar.canonical.com/BzrTools
207
208
209
変更内容をマージする
210
----------------------
211
212
``doodle-fixes`` での変更内容をメインのブランチにマージすることになったら、単にこうするだけです。::
213
214
% cd ~/work/sigil/dev
215
% bzr merge ../doodle-fixes
216
217
これで、変更内容は ``dev`` ブランチ上でもアクセスできるようになりますが、まだコミットはされていません。
218
最終的な変更内容をレビューして、コードがちゃんとコンパイルでき、テストをパスすることを確認したいならこの時です。
219
``bzr status`` コマンドと ``bzr diff`` コマンドがここで役立ちます。
220
また、競合を解決するのもこの時です。Bazaar_ では、競合を解決するまではコミットできないようになっています。
221
そのため、間違って競合マーカーをコミットしてしまうことはありません。
222
``bzr status`` コマンドを使えば、他の変更内容と一緒に競合の情報も表示されます。
223
``bzr conflicts`` なら、競合の情報だけが表示されます。
224
競合を解決し終わったら、``bzr resolve file/name`` か ``bzr resolve --all`` を実行してください。
225
[#resolve]_ もし、解決が特に難しい競合がある場合は、 ``bzr remerge`` コマンドを使いたいと思うかもしれません。
226
このコマンドで、別のマージアルゴリズムを試してみることができ、さらに元のソース行を表示する\
227
こともできます。(``--show-base``)
228
229
.. [#resolve] マージ実行中に競合の解決をさせるシステムもあります。
230
私たちは、ファイルごとに競合を解決するよりも、ツリー全体を見ながら競合を解決する方がたいていは簡単である\
231
ことに気づきました。
232
そうすれば、よりたくさんの情報を得られますし、問題を解決したときにテストを実行することもできます。
233
234
235
推奨のブランチ構成
236
---------------------
237
238
とても一般的なブランチ構成として、開発者ごとにひとつずつ専用のブランチを割り当て、中央サーバにも開発者ごとの\
239
作業領域を用意するという方法があります。これは以下のコマンドでできます。::
240
241
% bzr branch sftp://centralhost/srv/bzr/sigil \
242
sftp://centralhost/srv/bzr/sigil/user-a
243
% bzr branch sftp://centralhost/srv/bzr/sigil \
244
sftp://centralhost/srv/bzr/sigil/user-b
245
246
これで、開発者ごとに専用の作業用ブランチを割り当てています。
247
さらに、開発者自身で [#cbranch]_ を使用して新しく新機能開発用ブランチを作成することも簡単にできます。
248
::
249
250
% bzr branch sftp://centralhost/srv/bzr/sigil/user-a \
251
sftp://centralhost/srv/bzr/sigil/user-a/feature
252
% cd ~/work/sigil
253
% bzr checkout sftp://centralhost/srv/bzr/sigil/user-a/feature myfeature
254
255
256
用語解説
257
=========
258
259
共用リポジトリ
260
--------------
261
262
Bazaar_ には、”共用リポジトリ”という概念があります。これは、CVSやSubversionのようなの他のRCSが持つ\
263
旧来の概念に似ています。
264
たとえば、Subversionでは、サーバ上のリポジトリにすべての履歴情報が保存されていて、手元には履歴情報は\
265
全くなく、作業ツリーのファイルのチェックアウトがあるだけです。
266
ここで言う”共用”というのは、ブランチ同士の間で共用するという意味であることに注意してください。
267
開発者間でも共用される *かも知れません* が、開発者間での共用はスタンドアロンブランチでも可能です。
268
269
Bazaar_ の用語では、"共用リポジトリ"とは複数のブランチが履歴情報を **共有** できる場所のことです。
270
分散型のワークフローに対応するためには、それぞれのブランチが履歴情報を持っている必要があります。
271
しかし、しばしばこれは非効率です。関連するブランチ同士は履歴を共有しており、ディスクも共有した方が\
272
いいためです。
273
274
275
..
276
vim: tw=74 ft=rst
1
========================================
2
集中型ワークフローのチュートリアル
3
========================================
4
5
6
概要
7
====
8
9
この文書では、 Bazaar_ を使用することで実現可能なワークフローについて説明します。
10
つまり、分散バージョンコントロールシステムである Bazaar_ を、集中型のやり方で使用するためのワークフローです。
11
Bazaar_ は、非常にフレキシブルに設計されており、完全な分散型からほとんど集中型のワークフローまで、\
12
いくつかの異なるワークフローを受け入れることができます。
13
このワークフローは、初めてのユーザでも簡単に Bazaar_ を使いこなすことができ、\
14
分散型と集中型のオペレーションを組み合わせた業務にも対応できるようになっています。
15
16
基本的に、この文書はCVSやSubvresionのような集中型バージョンコントロールシステムの経験があるユーザ向けに書かれています。
17
これらの環境では、一般的に、コードベースをホストする単一の中央サーバが存在し、複数の人々がこのコードベース上で作業して、\
18
お互いの作業の同期をとることになります。
19
また、このワークフローは、一人の開発者が複数のマシーン上で作業をする場合にも適用できます。
20
21
.. _Bazaar: http://bazaar.canonical.com
22
23
24
初期セットアップ
25
================
26
27
Bazaar_ がうまく動くようにするための、まあまあ簡単なセットアップ手順があります。
28
29
ユーザのEメールの設定
30
---------------------
31
32
ユーザIDは各コミットに保存されます。これは正確だったり一意だったりする必要はありませんが、\
33
ログメッセージや注釈で使用されるため、何かしら実在する値を設定しておいた方がよいでしょう。
34
35
::
36
37
% bzr whoami "John Doe <jdoe@organization.com>"
38
39
40
ローカルリポジトリのセットアップ
41
--------------------------------
42
43
Bazaar_ のブランチは、通常は履歴のコピーを持っています。そのおかげで分散型での作業ができるわけです。
44
最適化の方法の一つとして、関連するブランチ同士の情報を統合して、\
45
新しいブランチを作るたびに履歴情報を丸ごとコピーしなくてもいいようにすることができます。
46
47
そのための一番いい方法は、 `共用リポジトリ`_ を作成することです。
48
一般に、 `共用リポジトリ`_ のサブディレクトリ内に複数のブランチがある場合、お互いの記憶領域を共有します。
49
ですので、ホームディレクトリに `共用リポジトリ`_ を作成するようにしましょう。
50
そうすれば、その下に作成したすべてのブランチは、履歴情報の領域を共有することになります。
51
52
::
53
54
% bzr init-repo --trees ~
55
56
57
リモートリポジトリのセットアップ
58
---------------------------------
59
60
作業用の領域とは別に、データを蓄積しておく領域が欲しいというのはよくあることです。
61
集中型のシステム(CVS/SVN)では、このようなワークフローが必要になります。
62
たいていは、これらは別々のマシーンに分けて配置されます。(そうでないこともあります。)
63
実際のところ、これは、特に職場ではとてもよい設定です。
64
蓄積されたデータはバックアップを確実にとることができ、開発者のマシーンに何かトラブルが起こっても\
65
コミットされたデータはけっして無くなりません。
66
67
それでは、プロジェクト内で共有する ``centralhost`` というマシーンを用意しましょう。
68
先ほども言いましたが、ディスクの使用量を節約するために、 `共用リポジトリ`_ を使用します。
69
70
::
71
72
% bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/
73
74
この手順は、新しくcvsrootやSubversionのリポジトリを作るのと同じようなものだと考えることができます。
75
``--no-tree`` オプションの指定によって、ワーキングツリーを作らないようになります。
76
中央リポジトリ内のブランチを直接変更することは無いので、このオプションを指定しておくとよいでしょう。
77
78
ここで、 ``bzr+ssh`` というURLを使っていますが、これは、 SSH セキュアシェ
79
ル上の
80
Bazaar 独自プロトコルを意味しています。 bzr+ssh サーバーのセットアップに関
81
する
82
情報に着いては、管理者向けガイドを参照してください。
83
84
85
86
既存のプロジェクトからの移行
87
=============================
88
89
リポジトリができましたので、プロジェクトの作成にかかりましょう。
90
たいていの場合、 Bazaar_ でバージョン管理したい作業中のコードがすでにあるはずです。
91
もし、そのコードがもともとソース管理されていたのであれば、履歴の情報を保ったまま Bazaar_ に\
92
変換する方法がたくさんあります。
93
しかしながら、それについてはここでは説明しません。詳しくは、 `Tracking Upstream`_ の\
94
"Converting and keeping history"セクションを見てください。
95
96
.. _Tracking Upstream: http://wiki.bazaar.canonical.com/TrackingUpstream
97
98
..
99
XXX: プロジェクトの変換について話をするための別の文書が必要なのですが、\
100
今ある中ではTrackingUpstreamが一番よい文書です。
101
102
103
Developer 1: 最初のリビジョンを作成する
104
-----------------------------------------
105
106
まず最初に、プロジェクトをホストするリモートリポジトリに、ブランチを作成したいと思います。
107
仮に、"sigil"というプロジェクトをバージョン管理しようとしているとしましょう。
108
109
::
110
111
% bzr init bzr+ssh://centralhost/srv/bzr/sigil
112
113
これは、CVSで言うところの"HEAD"ブランチ、Subversionなら"trunk"にあたるものだと考えてかまいません。
114
これを ``dev`` ブランチと呼ぶことにしましょう。
115
116
他のファイルとの競合を避けるために、ホームディレクトリのサブディレクトリ内で作業するのが私の好みです。
117
同じように、最終的にでき上がるすべてのブランチを格納できるプロジェクトディレクトリも欲しいですね。
118
::
119
120
% cd ~
121
% mkdir work
122
% cd work
123
% mkdir sigil
124
% cd sigil
125
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
126
% cd dev
127
% cp -ar ~/sigil/* .
128
% bzr add
129
% bzr commit -m "Initial import of Sigil"
130
131
前のセクションでは、空のブランチ(``sigil`` ブランチ)を ``centralhost`` に作成して、\
132
それをクライアント端末にチェックアウトしたあと、元々あったプロジェクトのファイルを追加しています。
133
作業ディレクトリをセットアップするための方法はたくさんありますが、この方法を使うと機能追加用/バグフィックス用\
134
のブランチを使った作業が簡単にできます。
135
そして、複数のブランチをとてもうまく扱えるというのが、 Bazaar_ の長所の一つなのです。
136
137
この場合、リモートブランチのチェックアウトを持っているので、 ``~/work/sigil/dev/`` に対してコミットした内容が、\
138
ローカルと ``centralhost`` の両方に自動的に保存される訳です。
139
140
141
Developer N: プロジェクトの作業コピーを取得する
142
--------------------------------------------------
143
144
プロジェクトの作成に関するすべての作業は1人目の開発者がしてしまっているので、\
145
他のみんなは単にそのブランチをチェックアウトするだけです。
146
**ただし、** `ユーザのEメールの設定`_ **と** `ローカルリポジトリのセットアップ`_ **は見ておいてください。**
147
148
現在開発中のツリーのコピーを取得するためには::
149
150
% cd ~/work/sigil
151
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
152
153
今、二人の人が ``bzr+ssh://centralhost/srv/bzr/sigil`` のチェックアウトを持っている状態なので、\
154
片方のチェックアウトが最新のものより古くなってしまうタイミングが出てきます。
155
コミットの時に、チェックアウトが古いければ Bazaar_ がエラーを返して、コミットは失敗します。
156
チェックアウトを最新にするには、よそで変更されたツリーに対して ``bzr update`` を使用します。
157
この時、もし同じファイルが変更されていれば、競合の解決が必要になるかもしれません。
158
159
160
別ブランチでの開発
161
====================
162
163
ここまでは、全員が同じブランチで作業して、変更をコミットしていました。
164
これはつまり、全員が適正かつ定期的にアップデートを行い、他の人の変更を取り扱う必要があると\
165
いうことです。
166
また、誰か一人が何かコードを壊すような変更をコミットして、それが同期されれば、\
167
全員が問題を抱えることになります。
168
169
たいていの場合、別のブランチ上で開発を行い、コードが安定してからメインのブランチに統合する\
170
というやり方の方が優れています。これが、CVSやSVNとの一番大きな違いです。
171
CVSやSVNも別ブランチでの開発はできますが、マージのアルゴリズムがかなり貧弱なので、\
172
ブランチ間できちんと同期がとれた状態に保つのは難しいことです。
173
Bazaar_ は、何がマージ済みかを記憶し、たとえファイルが変名されてる場合でもちゃんと変更を\
174
適用することができます。
175
176
177
新しいブランチを作成してそこで作業する
178
---------------------------------------
179
まだ変更が完了していない場合でも、他の人がその変更内容にアクセスできるようにしておきたいですよね。
180
そこで、 ``centralhost`` 上に新しい公開ブランチを作成して、それを手元に持ってくることにしましょう。
181
182
::
183
184
% cd ~/work/sigil
185
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
186
bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes
187
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
188
% cd doodle-fixes
189
190
これで、 ``doodle`` に必要な修正を当てるための場所ができました。
191
また、他の部分の修正をする人に邪魔されることもありません。
192
チェックアウトを持っているため、 ``~/work/sigil/doodle-fixes/`` に対してコミットした内容は\
193
``centralhost`` 上にも現れます。
194
[#nestedbranches]_ ``dev`` ブランチと同じように、このようなブランチ上で二人の開発者が共同で\
195
作業することもできます。
196
[#cbranch]_
197
198
.. [#nestedbranches] あるブランチのサブディレクトリに別のブランチがあるというのはおかしなこと\
199
に見えるかもしれませんが、これは何もおかしくありません。入れ子になったブランチは外側のブランチ\
200
から派生しているという点で、名前空間の階層と同じようなものだと考えることができます。
201
202
.. [#cbranch] たくさんの独立したブランチを使っている場合、毎回フルURLを入力するのは大変です。
203
このURLの入力を簡単にするために、ブランチエイリアスなどたくさんの方法を検討しています。
204
今のところ、 bzrtools_ プラグインが ``bzr cbranch`` コマンドを提供しています。
205
これは、ベースとなるブランチを指定して、新しく公開ブランチを作成し、そのチェックアウトを作成する\
206
ことを少ない入力でできるように設計されています。
207
``cbranch`` の使い方についてはこの文書の範囲外ですが、最後のコマンドについてはこんな感じです。:
208
209
::
210
211
% bzr cbranch dev my-feature-branch
212
213
.. _bzrtools: http://wiki.bazaar.canonical.com/BzrTools
214
215
216
変更内容をマージする
217
----------------------
218
219
``doodle-fixes`` での変更内容をメインのブランチにマージすることになったら、単にこうするだけです。::
220
221
% cd ~/work/sigil/dev
222
% bzr merge ../doodle-fixes
223
224
これで、変更内容は ``dev`` ブランチ上でもアクセスできるようになりますが、まだコミットはされていません。
225
最終的な変更内容をレビューして、コードがちゃんとコンパイルでき、テストをパスすることを確認したいならこの時です。
226
``bzr status`` コマンドと ``bzr diff`` コマンドがここで役立ちます。
227
また、競合を解決するのもこの時です。Bazaar_ では、競合を解決するまではコミットできないようになっています。
228
そのため、間違って競合マーカーをコミットしてしまうことはありません。
229
``bzr status`` コマンドを使えば、他の変更内容と一緒に競合の情報も表示されます。
230
``bzr conflicts`` なら、競合の情報だけが表示されます。
231
競合を解決し終わったら、``bzr resolve file/name`` か ``bzr resolve --all`` を実行してください。
232
[#resolve]_ もし、解決が特に難しい競合がある場合は、 ``bzr remerge`` コマンドを使いたいと思うかもしれません。
233
このコマンドで、別のマージアルゴリズムを試してみることができ、さらに元のソース行を表示する\
234
こともできます。(``--show-base``)
235
236
.. [#resolve] マージ実行中に競合の解決をさせるシステムもあります。
237
私たちは、ファイルごとに競合を解決するよりも、ツリー全体を見ながら競合を解決する方がたいていは簡単である\
238
ことに気づきました。
239
そうすれば、よりたくさんの情報を得られますし、問題を解決したときにテストを実行することもできます。
240
241
242
推奨のブランチ構成
243
---------------------
244
245
とても一般的なブランチ構成として、開発者ごとにひとつずつ専用のブランチを割り当て、中央サーバにも開発者ごとの\
246
作業領域を用意するという方法があります。これは以下のコマンドでできます。::
247
248
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
249
bzr+ssh://centralhost/srv/bzr/sigil/user-a
250
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
251
bzr+ssh://centralhost/srv/bzr/sigil/user-b
252
253
これで、開発者ごとに専用の作業用ブランチを割り当てています。
254
さらに、開発者自身で [#cbranch]_ を使用して新しく新機能開発用ブランチを作成することも簡単にできます。
255
::
256
257
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil/user-a \
258
bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature
259
% cd ~/work/sigil
260
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature myfeature
261
262
263
用語解説
264
=========
265
266
共用リポジトリ
267
--------------
268
269
Bazaar_ には、”共用リポジトリ”という概念があります。これは、CVSやSubversionのようなの他のRCSが持つ\
270
旧来の概念に似ています。
271
たとえば、Subversionでは、サーバ上のリポジトリにすべての履歴情報が保存されていて、手元には履歴情報は\
272
全くなく、作業ツリーのファイルのチェックアウトがあるだけです。
273
ここで言う”共用”というのは、ブランチ同士の間で共用するという意味であることに注意してください。
274
開発者間でも共用される *かも知れません* が、開発者間での共用はスタンドアロンブランチでも可能です。
275
276
Bazaar_ の用語では、"共用リポジトリ"とは複数のブランチが履歴情報を **共有** できる場所のことです。
277
分散型のワークフローに対応するためには、それぞれのブランチが履歴情報を持っている必要があります。
278
しかし、しばしばこれは非効率です。関連するブランチ同士は履歴を共有しており、ディスクも共有した方が\
279
いいためです。
280
281
282
..
283
vim: tw=74 ft=rst
Loggerhead is a web-based interface for Breezy
Version: 2.0.1