← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: John Whitley
  • Date: 2010-01-11 16:44:02 UTC
  • mto: This revision was merged to the branch mainline in revision 4981.
  • Revision ID: whitley@bangpath.org-20100111164402-9luag9p9ahpy4kmz
Terminology change: exclusion => exception.
Tweaked presentation of new logic in ExceptionGlobster

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ja/user-guide/adv_merging.txt
 
1
疑似マージ
 
2
===========
 
3
 
 
4
チェリーピッキング
 
5
------------------
 
6
 
 
7
時々、ブランチの変更の全部ではなく一部だけを選んでマージすることが\
 
8
便利であることがあります。
 
9
これは一般的に *チェリーピッキング(cherrypicking)* として言及されます。
 
10
 
 
11
チェリーピッキングが役に立ついくつかの事例:
 
12
 
 
13
* メインの開発ブランチから修正の一部を取り出してリリースブランチに取り込む
 
14
 
 
15
* 実験ブランチから改善内容を選別して機能ブランチに取り込む
 
16
 
 
17
``foo`` ブランチのリビジョン Xによってなされた変更のみをマージするためには::
 
18
 
 
19
  bzr merge -c X foo
 
20
 
 
21
``foo`` ブランチのリビジョンXまでの変更のみをマージするためには::
 
22
 
 
23
  bzr merge -r X foo
 
24
 
 
25
``foo`` のリビジョンX以降の変更のみをマージするためには::
 
26
 
 
27
  bzr merge -r X.. foo
 
28
 
 
29
``foo`` ブランチのリビジョンXからリビジョンYまでの変更のみをマージするには::
 
30
 
 
31
  bzr merge -r X..Y foo
 
32
 
 
33
通常のマージと同じように、チェリーピックは明示的にコミットしなければなりません。
 
34
これを行う前に、 ``bzr diff`` を利用した変更を見て何かあればテストスイートを\
 
35
実行するとよいでしょう。
 
36
 
 
37
通常のマージとは異なり、Bazaarは現在はチェリーピックを追跡しません。
 
38
具体的に言うと、変更は通常のコミットと同じようになり、他のブランチから来た(内部の)変更履歴は失われます。
 
39
上記のようなチェリーピックが役に立つ場面では、このことはたいてい重大な問題ではありません。
 
40
フルマージが後で行われることはけっしてないと言える十分な理由があるからです。
 
41
そうではない場面では、変更が再びマージされたときにまた衝突を解消する必要があります。
 
42
 
 
43
.. _reverse-cherrypicking:
 
44
 
 
45
リバースチェリーピッキング
 
46
---------------------------
 
47
 
 
48
チェリーピッキングは一連の変更を元に戻すことができます。この場合、リビジョン範囲の\
 
49
上界(upper bound)が下界(lower bound)よりも *小さく* なります。
 
50
たとえば、リビジョン10の変更を取り消すためのコマンドはこうなります::
 
51
 
 
52
  bzr merge -r 10..9
 
53
 
 
54
どこかから、すべてではない大半の変更を得たい場合通常のマージをした後に少しの\
 
55
リバースチェリーピックを行うとよいでしょう。
 
56
 
 
57
 
 
58
コミットされていない変更をマージする
 
59
-------------------------------------
 
60
 
 
61
複数のブランチを持っており、間違えて別のブランチを変更し始めた場合、訂正をとるステップは次のとおりです。
 
62
ブランチ ``bar`` で作業したかったのに、ブランチ ``foo`` で作業を始めてしまったという場合を前提とします:
 
63
 
 
64
1. ``bar`` ブランチに移動する
 
65
2. ``bzr merge --uncommitted foo`` を実行する
 
66
3. やってくる変更をチェックする (``bzr diff``)
 
67
4. ``foo`` ブランチに変更する
 
68
5. ``bzr revert`` を実行する
 
69
 
 
70
.. TODO Selective file merging?
 
71
 
 
72
 
 
73
リベースする
 
74
--------------
 
75
 
 
76
通常のマージの別のオプションは *リベース(rebase)* です。
 
77
すなわち、現在のブランチが本来とは異なる地点をベースにするようにします。
 
78
リベースは ``rebase`` プラグインによって提供される ``rebase`` コマンド\
 
79
によってサポートされます。
 
80
 
 
81
``rebase`` コマンドは現在の作業ディレクトリ内のリベースされるブランチ上で\
 
82
別のブランチの位置をとります。
 
83
ブランチが指定されないと親のブランチが使われ、通常これは望まれる結果です。
 
84
 
 
85
最初のステップは現在のブランチのものであるが親のブランチではないリビジョンを\
 
86
特定することです。
 
87
現在のブランチはターゲットブランチと同じリビジョンに設定され、それぞれの\
 
88
リビジョンはブランチのトップで再現されます。
 
89
プロセスの終了時に現在のブランチがターゲットの最終リビジョンからブランチ\
 
90
されたようになります。
 
91
 
 
92
再現されるそれぞれのリビジョンがツリーの中で衝突を起こすことがあります。
 
93
これが起きたらコマンドは停止してそれらを修正しなければなりません。
 
94
``merge`` するためにコミットを解消し、それらが解消されたものとしてマークするために
 
95
``bzr resolve`` を実行します。
 
96
すべての衝突を解消したら、リベースオペレーションを続けるために ``bzr rebase-continue``
 
97
を実行します。
 
98
衝突に遭遇せず続けないことを決めたら、 ``bzr rebase-abort`` を実行できます。
 
99
リプレイされるコミットの一覧を表示するために ``rebase-todo`` を利用することもできます。
 
100
 
 
101
注: マージトラッキング機能が貧弱なVCSツールから来たユーザーの中にはリベースを好む人がいます。
 
102
古いツールでの作業方法に似ている、もしくは"完璧にきれいな" 履歴が重要だからです。
 
103
Bazaarでリベースする前に、通常のマージがベターな選択肢ではないのか考えてください。
 
104
とりわけ、始める前にプライベートなブランチをリベースするのは大丈夫ですが、
 
105
他の誰かとブランチを共有した後のリベースは **強く非推奨** です。