← 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: 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/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
 
.. Merging without parents
44
 
 
45
 
親のないマージ
46
 
------------------
47
 
 
48
 
チェリーピックに関連したテクニックとして、マージ元のリビジョンを参照せずに、
49
 
コミット前に親リビジョンを忘れることができます。
50
 
こうすると、このマージで行われた全ての変更が、1回のコミットで行われたような
51
 
効果があります。
52
 
マージしたあと、コミットする前に次のコマンドを実行します。 ::
53
 
 
54
 
  bzr revert --forget-merges
55
 
 
56
 
これで、作業ツリー内の変更は残したまま、その変更がどこからマージされたかの
57
 
記録だけを削除します。そして、次のコミットではマージされたリビジョンに
58
 
関する情報が一切ない状態で、全ての変更を記録します。
59
 
 
60
 
この機能は、「きれいな」履歴を作りたいユーザーに取って便利なものですが、
61
 
Bazaarはもともとマージされた履歴を段階的に表示する機能を持っているので、
62
 
失った履歴の価値が履歴のきれいさの価値を上回らないように気をつける必要があります。
63
 
特に、この機能を使うとマージ元の変更だけを取り込んでその変更のマージ元を
64
 
記録しないので、後で同じマージ元からマージしようとすると余計なコンフリクトを
65
 
発生させる可能性があります。
66
 
 
67
 
 
68
 
.. _reverse-cherrypicking:
69
 
 
70
 
リバースチェリーピッキング
71
 
---------------------------
72
 
 
73
 
チェリーピッキングは一連の変更を元に戻すことができます。この場合、リビジョン範囲の\
74
 
上界(upper bound)が下界(lower bound)よりも *小さく* なります。
75
 
たとえば、リビジョン10の変更を取り消すためのコマンドはこうなります::
76
 
 
77
 
  bzr merge -r 10..9
78
 
 
79
 
どこかから、すべてではない大半の変更を得たい場合通常のマージをした後に少しの\
80
 
リバースチェリーピックを行うとよいでしょう。
81
 
 
82
 
 
83
 
コミットされていない変更をマージする
84
 
-------------------------------------
85
 
 
86
 
複数のブランチを持っており、間違えて別のブランチを変更し始めた場合、訂正をとるステップは次のとおりです。
87
 
ブランチ ``bar`` で作業したかったのに、ブランチ ``foo`` で作業を始めてしまったという場合を前提とします:
88
 
 
89
 
1. ``bar`` ブランチに移動する
90
 
2. ``bzr merge --uncommitted foo`` を実行する
91
 
3. やってくる変更をチェックする (``bzr diff``)
92
 
4. ``foo`` ブランチに変更する
93
 
5. ``bzr revert`` を実行する
94
 
 
95
 
.. TODO Selective file merging?
96
 
 
97
 
 
98
 
リベースする
99
 
--------------
100
 
 
101
 
通常のマージの別のオプションは *リベース(rebase)* です。
102
 
すなわち、現在のブランチが本来とは異なる地点をベースにするようにします。
103
 
リベースは ``rebase`` プラグインによって提供される ``rebase`` コマンド\
104
 
によってサポートされます。
105
 
 
106
 
``rebase`` コマンドは現在の作業ディレクトリ内のリベースされるブランチ上で\
107
 
別のブランチの位置をとります。
108
 
ブランチが指定されないと親のブランチが使われ、通常これは望まれる結果です。
109
 
 
110
 
最初のステップは現在のブランチのものであるが親のブランチではないリビジョンを\
111
 
特定することです。
112
 
現在のブランチはターゲットブランチと同じリビジョンに設定され、それぞれの\
113
 
リビジョンはブランチのトップで再現されます。
114
 
プロセスの終了時に現在のブランチがターゲットの最終リビジョンからブランチ\
115
 
されたようになります。
116
 
 
117
 
再現されるそれぞれのリビジョンがツリーの中で衝突を起こすことがあります。
118
 
これが起きたらコマンドは停止してそれらを修正しなければなりません。
119
 
``merge`` するためにコミットを解消し、それらが解消されたものとしてマークするために
120
 
``bzr resolve`` を実行します。
121
 
すべての衝突を解消したら、リベースオペレーションを続けるために ``bzr rebase-continue``
122
 
を実行します。
123
 
衝突に遭遇せず続けないことを決めたら、 ``bzr rebase-abort`` を実行できます。
124
 
リプレイされるコミットの一覧を表示するために ``rebase-todo`` を利用することもできます。
125
 
 
126
 
注: マージトラッキング機能が貧弱なVCSツールから来たユーザーの中にはリベースを好む人がいます。
127
 
古いツールでの作業方法に似ている、もしくは"完璧にきれいな" 履歴が重要だからです。
128
 
Bazaarでリベースする前に、通常のマージがベターな選択肢ではないのか考えてください。
129
 
とりわけ、始める前にプライベートなブランチをリベースするのは大丈夫ですが、
130
 
他の誰かとブランチを共有した後のリベースは **強く非推奨** です。