← 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: Patch Queue Manager
  • Date: 2015-10-05 13:45:00 UTC
  • mfrom: (6603.3.1 bts794146)
  • Revision ID: pqm@pqm.ubuntu.com-20151005134500-v244rho557tv0ukd
(vila) Resolve Bug #1480015: Test failure: hexify removed from paramiko
 (Andrew Starr-Bochicchio) (Andrew Starr-Bochicchio)

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