7
誰かがプロジェクトの独自ブランチを持ったら、 並行して変更を行い、\
8
オリジナルのブランチを続ける開発にコミットできます。
9
まもなくですが、開発の独立したラインを結合することが必要にあります。
10
このプロセスは *マージ (merging)* として知られます。
15
別のブランチから変更を受け入れるためには、 ``merge`` コマンドを使います。
20
URLが渡されない場合、オリジナルのものから由来する初期のブランチがデフォルト\
22
たとえば、BillがMaryの作業内容からブランチを作る場合、
23
下記のようにコマンドを入力すれば彼女の次の変更をマージできます::
27
一方で、MaryはBillのブランチで行われた作業内容を彼女のブランチにマージ\
29
この場合、彼女は最初に明示的にURLを渡す必要があります::
31
bzr merge sftp://mary@bill-laptop/cool-repo/cool-trunk
33
マージブランチがまだ設定されていなければ、これによってデフォルトの\
35
設定した後でデフォルトを変更するためには、 ``--remember`` オプション\
41
マージのためのいくつかのアルゴリズムがあります。
42
Bazaarのデフォルトのアルゴリズムは次のように動作する
43
*3方向マージ (3-way merging)* の一種です。
44
Aが祖先でBとCの2つがブランチであると仮定すると、次のテーブルは使われるルールを\
47
=== === === ====== =================
49
=== === === ====== =================
54
=== === === ====== =================
56
マージの中には人間の手助けによってのみ完了するものがあることに留意してください。
57
これらを解決する方法の詳細は `衝突を解消する <resolving_conflicts.html>`_ を参照してください。
62
衝突が解決した後で、マージをコミットする必要があります。例です::
64
bzr commit -m "Merged Mary's changes"
66
衝突が無くても、明確なコミットがまだ必要です。
67
他のツールとは異なり、これはBazaarの機能と考えられています。
68
クリーンなマージは必ずしもよいマージとは限らないので、個別の明確なステップ\
69
としてコミットすることで、すべてがよい状態にあることを検証するための最初の\
72
問題が見つかったら、マージをコミットする前にそれらを訂正する\
73
もしくは ``revert`` を使用してマージを廃棄すべきです。
78
Bazaarの機能の中で最も重要な機能の1つは、分散型で高品質の\
80
言い換えると、Bazaarは何がすでにマージされていることを覚えており、\
81
マージのための最良の祖先を賢く選ぶためにその情報を使い、\
84
あなたが他の多くのVCSツールの難民であるなら、
85
*何が何でもマージは避けさせてください* という習慣から抜け出すのは\
87
Bazaarによっていつでも安全に他の人とのマージを行うことができます。
88
peer-to-peerの方法でうまくゆくときに、高い品質を保つために、
89
"統合のたまり場"として集中型のブランチを使うことも避けられます。
90
コラボレーションしている変更を本当に広く共有する準備ができたら、\
91
変更を中心のブランチにマージしてコミットする機会です。
93
このようにマージ機能がうまくゆけば開発者の共同作業の方法を変えることができます。
added
removed
doc/ja/user-guide/merging_changes.txt
