← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2008-09-03 22:30:56 UTC
  • mfrom: (3644.2.13 index_builder_cleanup)
  • Revision ID: pqm@pqm.ubuntu.com-20080903223056-b108iytb38xkznci
(jam) Streamline BTreeBuilder.add_node et al to make btree creation
        faster.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ja/user-guide/using_gatekeepers.txt
1
 
ゲートキーパーを利用する
2
 
=========================
3
 
 
4
 
分散型の人間のゲートキーパーのワークフロー
5
 
-------------------------------------------
6
 
 
7
 
このワークフローでは、1人の開発者(ゲートキーパー) がメインブランチへの\
8
 
コミット権限を持つ一方で他の開発者はリードオンリーの権限のみを持ちます。
9
 
すべての開発者はタスクブランチの中で変更を行います。
10
 
 
11
 
.. image:: images/workflows_gatekeeper.png
12
 
 
13
 
開発者は彼らの作業内容をマージしたいとき、ゲートキーパーに彼らの変更を\
14
 
レビューして受け入れ可能であればマージするよう頼みます。
15
 
変更がレビューを失敗するとき、準備ができるまで関連のタスクブランチで\
16
 
さらなる開発が進みます。
17
 
 
18
 
このアプローチの主要な面は含まれる制御の反転です:
19
 
開発者は変更を中心ブランチに"コミット/プッシュ"するときを決めなくて済みます:
20
 
コードベースはゲートキーパーの "マージ/プル" による統制された変更方法によって発展します。
21
 
複数の中心ブランチとそれぞれ異なるゲートキーパーをを持つことはとてもよい方法で、
22
 
よく採用されている方法です。。
23
 
たとえば、現在の製品リリースと次のリリースのためにそれぞれ1つづつのブランチがあります。
24
 
この場合、たいがいはバグ修正を保持するタスクブランチは両方のゲートキーパーによって\
25
 
通知されます。
26
 
 
27
 
このワークフローのすばらしい点の一つはスケーラブルであることです。
28
 
大きなプロジェクトはチームになりそれぞれのチームはゲートキーパーによって管理される
29
 
*ローカルマスターブランチ* を持つことができます。
30
 
チームリーダーがリクエストするときにチームのマスターブランチからの変更を\
31
 
プライマリマスターブランチにマージするために誰かを主席ゲートキーパーに任命できます。
32
 
 
33
 
分散型の自動ゲートキーパーのワークフロー
34
 
-----------------------------------------
35
 
 
36
 
より高い品質を得るために、すべての開発者は変更を回帰テストスイートが通ったら\
37
 
変更のマージとコミットだけを行う自動ゲートキーパーに投稿できることが求められます。
38
 
このようなゲートキーパーの1つはPQMと呼ばれるソフトウェアツールです。
39
 
 
40
 
.. image:: images/workflows_pqm.png
41
 
 
42
 
PQMに関する詳細な情報に関しては、 https://launchpad.net/pqm を参照してください。