← 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: Alexander Belchenko
  • Date: 2006-07-30 16:43:12 UTC
  • mto: (1711.2.111 jam-integration)
  • mto: This revision was merged to the branch mainline in revision 1906.
  • Revision ID: bialix@ukr.net-20060730164312-b025fd3ff0cee59e
rename  gpl.txt => COPYING.txt

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
 
他の誰かとブランチを共有した後のリベースは **強く非推奨** です。