← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2007-03-28 06:58:22 UTC
  • mfrom: (2379.2.3 hpss-chroot)
  • Revision ID: pqm@pqm.ubuntu.com-20070328065822-999550a858a3ced3
(robertc) Fix chroot urls to not expose the url of the transport they are protecting, allowing regular url operations to work on them. (Robert Collins, Andrew Bennetts)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ja/user-guide/merging_changes.txt
1
 
変更をマージする
2
 
=================
3
 
 
4
 
並行開発
5
 
---------
6
 
 
7
 
誰かがプロジェクトの独自ブランチを持ったら、 並行して変更を行い、\
8
 
オリジナルのブランチを続ける開発にコミットできます。
9
 
まもなくですが、開発の独立したラインを結合することが必要にあります。
10
 
このプロセスは *マージ (merging)* として知られます。
11
 
 
12
 
mergeコマンド
13
 
-------------
14
 
 
15
 
別のブランチから変更を受け入れるためには、 ``merge`` コマンドを使います。
16
 
構文は次のとおりです::
17
 
 
18
 
  bzr merge [URL]
19
 
 
20
 
URLが渡されない場合、オリジナルのものから由来する初期のブランチがデフォルト\
21
 
として使われます。
22
 
たとえば、BillがMaryの作業内容からブランチを作る場合、
23
 
下記のようにコマンドを入力すれば彼女の次の変更をマージできます::
24
 
 
25
 
  bzr merge
26
 
 
27
 
一方で、MaryはBillのブランチで行われた作業内容を彼女のブランチにマージ\
28
 
したいかもしれません。
29
 
この場合、彼女は最初に明示的にURLを渡す必要があります::
30
 
 
31
 
  bzr merge bzr+ssh://mary@bill-laptop/cool-repo/cool-trunk
32
 
 
33
 
マージブランチがまだ設定されていなければ、これによってデフォルトの\
34
 
マージブランチが設定されます。
35
 
設定した後でデフォルトを変更するためには、 ``--remember`` オプション\
36
 
を使います。
37
 
 
38
 
マージの動作方法は？
39
 
--------------------
40
 
 
41
 
マージのためのいくつかのアルゴリズムがあります。
42
 
Bazaarのデフォルトのアルゴリズムは次のように動作する
43
 
*3方向マージ (3-way merging)* の一種です。
44
 
Aが祖先でBとCの2つがブランチであると仮定すると、次のテーブルは使われるルールを\
45
 
提示します。
46
 
 
47
 
  === === === ====== =================
48
 
   A   B   C  結果   コメント
49
 
  === === === ====== =================
50
 
   x   x   x  x      unchanged
51
 
   x   x   y  y      line from C
52
 
   x   y   x  y      line from B
53
 
   x   y   z  ?      conflict
54
 
  === === === ====== =================
55
 
 
56
 
マージの中には人間の手助けによってのみ完了するものがあることに留意してください。
57
 
これらを解決する方法の詳細は `衝突を解消する <resolving_conflicts.html>`_ を参照してください。
58
 
 
59
 
マージを記録する
60
 
-----------------
61
 
 
62
 
衝突が解決した後で、マージをコミットする必要があります。例です::
63
 
 
64
 
  bzr commit -m "Merged Mary's changes"
65
 
 
66
 
衝突が無くても、明確なコミットがまだ必要です。
67
 
他のツールとは異なり、これはBazaarの機能と考えられています。
68
 
クリーンなマージは必ずしもよいマージとは限らないので、個別の明確なステップ\
69
 
としてコミットすることで、すべてがよい状態にあることを検証するための最初の\
70
 
テストスィートを実行できます。
71
 
 
72
 
問題が見つかったら、マージをコミットする前にそれらを訂正する\
73
 
もしくは ``revert`` を使用してマージを廃棄すべきです。
74
 
 
75
 
マージの追跡
76
 
------------
77
 
 
78
 
Bazaarの機能の中で最も重要な機能の1つは、分散型で高品質の\
79
 
*マージトラッキング* です。
80
 
言い換えると、Bazaarは何がすでにマージされていることを覚えており、\
81
 
マージのための最良の祖先を賢く選ぶためにその情報を使い、\
82
 
衝突の回数と規模を最小にします。
83
 
 
84
 
あなたが他の多くのVCSツールの難民であるなら、
85
 
*何が何でもマージは避けさせてください* という習慣から抜け出すのは\
86
 
本当に難しいかもしれません。
87
 
Bazaarによっていつでも安全に他の人とのマージを行うことができます。
88
 
peer-to-peerの方法でうまくゆくときに、高い品質を保つために、
89
 
"統合のたまり場"として集中型のブランチを使うことも避けられます。
90
 
コラボレーションしている変更を本当に広く共有する準備ができたら、\
91
 
変更を中心のブランチにマージしてコミットする機会です。
92
 
 
93
 
このようにマージ機能がうまくゆけば開発者の共同作業の方法を変えることができます。