~bzr-pqm/bzr/bzr.dev : contents of doc/ja/user-guide/organizing_your

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

4634.99.1 by Naoki INADA import doc-ja rev90	1	.. _organizing-your-workspace:
	2
	3	作業スペースを構成する
	4	=========================
	5
	6	.. _common-workspace-layouts:
	7
	8	一般的なレイアウト
	9	---------------------
	10
	11	Bazaarのユーザーがプロジェクトのための作業スペースを構成するベストな方法は、\
	12	次のような要素に依存します:
	13
	14	* ユーザーの役割: プロジェクトオーナー vs コア開発者 vs カジュアルな貢献者
	15
	16	* ワークフロー: プロジェクトが推奨/強制している、貢献のためのワークフロー
	17
	18	* サイズ: 大きいプロジェクトは小さいプロジェクトよりもリソースを要求します。
	19
	20	少なくとも4つの一般的なワークスペースの構成方法があります。
	21
	22	* lightweight checkout
	23	* standalone tree
	24	* feature branches
	25	* switchable sandbox.
	26
	27	各レイアウトの簡単な説明を以下に記します。
	28
	29
	30	軽量チェックアウト
	31	--------------------
	32
	33	このレイアウトでは、作業ツリーはローカルですがブランチはリモートにあります。
	34	これはCVSやSVNで一般的に利用されるレイアウトで、シンプルで簡単に理解できます。
	35
	36	セットアップするには::
	37
	38	bzr checkout --lightweight URL project
	39	cd project
	40
	41	作業するには::
	42
	43	(make changes)
	44	bzr commit
	45	(make changes)
	46	bzr commit
	47
	48	各コミットが暗黙的に変更を同じブランチを利用している他の人に公開していることに\
	49	注意してください。ただし、コミットが成功するには作業ツリーがリモートのブランチの\
	50	最新の状態になっている必要があります。最新のコードを取得してマージするには、::
	51
	52	bzr update
	53
	54
	55	スタンドアロンツリー
	56	----------------------
	57
	58	このレイアウトでは、作業ツリーとブランチは一つの場所にあります。
	59	共有リポジトリが上位のディレクトリに無い限り、リポジトリも同じ場所に\
	60	格納されます。これはBazaarのデフォルトレイアウトで、小規模から中規模の\
	61	大きさのプロジェクトに適しています。
	62
	63	セットアップ::
	64
65	bzr branch URL project
66	cd project
67
68	作業::
69
70	(make changes)
71	bzr commit
72	(make changes)
73	bzr commit
74
75	変更を中央の場所に公開する::
76
77	bzr push [URL]
78
79	pushするURLは最初の一回だけ要求されます。
80
81	もし中央の場所が、pushするまでの間に他のユーザーからの変更を受け取っていた\
82	場合、pushする前にそれらの変更をローカルブランチにmergeする必要があります::
83
84	bzr merge
85	(resolve conflicts)
86	bzr commit
87
88	代替手段として、チェックアウトを使うこともできます。ブランチと同じように\
89	チェックアウトも履歴全体をローカルにコピーしますが、ローカルブランチが\
90	リモートの場所に束縛されているので、両方のブランチに一度にコミットされます。
91
92	注意: チェックアウトはローカルコミット+pushに比べてスマートです。
93	チェックアウトはまずリモートにコミットして、それが成功したときにだけ\
94	ローカルにもコミットします。
95
96	.. _feature-branches:
97
98	機能ブランチ
99	--------------
100
101	このレイアウトでは、いくつかのブランチとツリーがあって、一般的にリポジトリを共有します。
102	一つのブランチは "trunk" のミラーを保存していて、それ以外の作業単位(例:バグ修正や
103	機能追加)にはそれぞれの "機能ブランチ" を作ります。
104	このレイアウトはほとんどのプロジェクト、特に中規模のものにとって理想的です。
105
106	セットアップ::
107
108	bzr init-repo project
109	cd project
110	bzr branch URL trunk
111
112	機能ブランチを開始する::
113
114	bzr branch trunk featureX
115	cd featureX
116
117	作業する::
118
119	(make changes)
120	bzr commit
121	(make changes)
122	bzr commit
123
124	変更をメーリングリストに公開してレビュー&承認してもらう::
125
126	bzr send
127
128	変更を公開ブランチで公開する(たとえばLaunchpad上でmerge要求を出すために)::
129
130	bzr push [URL]
131
132	変化形として、trunkをチェックアウトとして作ることもできます。
133	もしtrunkへのコミット権限を持っているのであれば、trunkへマージして\
134	コミットするとその変更は暗黙的に公開されます。
135	他には、trunkのURLが読み込み専用だった場合(例: httpアドレス)、チェックアウトを\
136	利用することはローカルのtrunkミラーに間違えて変更を登録してしまうことを\
137	防止します。これはプロジェクトがPQMなどのゲートキーパー型のワークフロー\
138	を利用していたときに有用です。
139
140
141	.. _local-sandbox:
142
143	ローカルのsandbox
144	------------------
145
146	このレイアウトは機能ブランチのレイアウトとほぼ同じですが、機能ブランチが\
147	それぞれ作業ツリーを持つ代わりに一つの作業ツリーを共用する点が違います。
148	これはgitのデフォルトレイアウトに似ていて、大きなツリー(10000ファイル以上\
149	とか)を持つプロジェクトや、ビルドによる加工物(.oや.classファイルといった)\
150	を大量に作るプロジェクトに適しています。
151
152	セットアップ::
153
154	bzr init-repo --no-trees project
155	cd project
156	bzr branch URL trunk
157	bzr checkout --lightweight trunk sandbox
158	cd sandbox
159
160	これでsandboxで作業を開始できますが、sandboxがtrunkを参照したままコミット\
161	してしまうと、(trunkがcheckoutで無い限り)trunkが元のtrunkのミラーでは\
162	なくなってしまいます。
163	なので、まず機能branchを作ってsandboxをそちらに紐づけましょう::
164
165	bzr branch ../trunk ../featureX
166	bzr switch ../featureX
167
168	この後の、変更を行ったりその変更を公開して適用してもらうまでの\
169	プロセスは機能ブランチレイアウトの時と同じです。
170
171
172	進んだレイアウト
173	----------------
174
175	お望みとあれば、あなたのお好みの構成に合わせてレイアウトを決めることができます。
176	例やアイデアについては `共有リポジトリのレイアウト <shared_repository_layouts.html>`_
177	を参照してください。