Hg：gitのリベースのようなリベースの方法
Gitではこれを行うことができます。
1。 $ git co -b newfeature-123＃（ローカル機能開発ブランチ） いくつかのコミットを行います（M、N、O） マスターA --- B --- C \ newfeature-123 M --- N --- O 2。アップストリームマスターから新しい変更を取得します： $ git pull （ff-commitsで更新されたマスター） マスター-D --- E --- F \ newfeature-123 M --- N --- O 3。マスターをリベースして、新しい機能 を最新のアップストリームの変更に対して開発できるようにします。 （from newfeature-123） $ git rebase master マスターA --- B --- C --- D --- E --- F \ newfeature-123 M --- N --- O
私はMercurialで同じことをする方法を知りたいと思っており、答えをウェブで探しましたが、見つけることができた最高のものは： git rebase-hg do that
そのリンクは2つの例を提供します：
1。私はこれを認めます：（例のリビジョンを自分の例のリビジョンに置き換える）
hg up -C F hg branch -f newfeature-123 hg移植-a -b newfeature-123
リベース前のM-N-Oをマージされていないヘッドとして残し、更新されたメインラインから分岐することを表す3つの新しいコミットM '、N'、O 'を作成することを除いて、それほど悪くはありません。
基本的に問題は、私がこれで終わることです：
マスターA --- B --- C --- D --- E --- F \\ newfeature-123\M '--- N' --- O ' \ newfeature-123 M --- N --- O
これは、ドロップする必要があるローカルの不要なコミットを残すため、良くありません。
- 同じリンクからの他のオプションは
hg qimport -r M：O hg qpop -a hg up F hg branch newfeature-123 hg qpush -a hg qdel -r qbase：qtip
これにより、目的のグラフが作成されます。
マスターA --- B --- C --- D --- E --- F \ newfeature-123 M --- N --- O
しかし、これらのコマンド（6つすべて！）は、
$ git rebase master
これがHgで唯一の同等物であるか、またはGitのような単純な他の方法が利用できるかどうかを知りたいです。
VonCには、 探している答え 、Rebase Extensionがあります。ただし、Mercurialでmqもrebaseがデフォルトで有効になっていないのかを考えるのに1、2秒費やす価値があります。Mercurialはすべて、変更不可能な変更セットに関するものです。ほぼ毎日のように、あなたが説明している方法で作業するとき、私が取るパターンは次のとおりです。
1. Start working on a new feature:
$ hg clone mainline-repo newfeature-123
do a few commits (M, N, O)
master A---B---C
\
newfeature-123 M---N---O
2. Pull new changes from upstream mainline:
$ hg pull
master A---B---C---D---E---F
\
newfeature-123 M---N---O
3. merge master into my clone so that my new feature
can be developed against the latest upstream changes:
(from newfeature-123)
$ hg merge F
master A---B---C---D---E---F
\ \
newfeature-123 M---N---O---P
本当に必要なのはそれだけです。最終的には、新しいfeature-123クローンができました。満足したらメインラインに簡単にプッシュバックできます。しかし、最も重要なことは、I履歴を変更しないことです。誰かが私のcsetを見て、それらが元々コーディングされていたものと、作業全体を通してメインラインの変更にどのように反応したかを見ることができます。誰もがそれが価値があると考えているわけではありませんが、私たちが望んでいたことではなく、実際に何が起こったかを示すのはソース管理の仕事だと固く信じています-すべての行き止まりとリファクタリングは消えない痕跡を残し、リベースする必要があります他の履歴編集技術はそれを隠します。
それでは、ソープボックスを片付けている間にVonCの答えを選んでください。 :)
Rebase Extension を探しているかもしれません。 （ SummerOfCode 2008 ）の一部として実装
このような場合、ローカルの変更を「切り離し」、リポジトリをメインストリームと同期してから、新しいリモートの変更の上にプライベートな変更を追加すると便利です。この操作はリベースと呼ばれます。
取得 ：
に：
変更をプルしておらず、レポジトリに2つのブランチがある場合、（sing
keepbranches）：
hg up newfeature-123
hg rebase -d master --keepbranches
（--keepbranches：元のブランチ名を継承します。）
Mojca 言及：
hg rebase --source {L1's-sha} --dest {R2's-sha}を使用するのが好きですが、最後に--keepbranchesを追加できるとは知りませんでした。
以下に示す by Jonathan Blackburn ：
hg rebase -d default --keepbranches
最新のHgインストールがあると仮定すると、次を追加できます。
[extensions]
rebase =
〜/ .hgrcに。
その後、コマンドhg rebase、hg pull --rebase、またはhg help rebaseを使用できます。
上記の答えがOPの目標を達成するとは思わない。それは、彼のタスクブランチを維持することであり、親ブランチの後のポイントに対してリベースするだけだった。
このグラフから始めましょう（graphlog拡張を使用して生成されます。graphlogに対する深刻なオタク愛）。
@ 9a4c0eb66429 Feature 3 commit 2 tip feature3
|
| o af630ccb4a80 default againagainagain
| |
o | 98bdde5d2185 Feature 3 branch commit 1 feature3
|/
o e9f850ac41da foo
私がfeature3ブランチにいて、再度againagainコミットからリベースしたい場合、hg rebase -d defaultを実行することを理解しています。これには次の結果があります。
@ 89dada24591e Feature 3 commit 2 tip
|
o 77dcce88786d Feature 3 branch commit 1
|
o af630ccb4a80 default againagainagain
|
o e9f850ac41da foo
任務完了？そうは思いません。問題は、feature3ブランチでのコミットが再び再びゲインに基づいたときに、feature3ブランチが削除されたであることです。私のコミットはデフォルトのブランチに移動しましたが、そもそもそれを避けようとしていました。
Gitでは、結果は次のようになります。
@ 9a4c0eb66429 Feature 3 commit 2 tip
|
o 98bdde5d2185 Feature 3 branch commit 1 **feature3**
|
o af630ccb4a80 default againagainagain
|
o e9f850ac41da foo
Feature3ブランチがまだ存在し、2つのコミットがまだfeature3ブランチ上にあり、デフォルトでは表示されないことに注意してください。タスクブランチを保存しないと、これがマージとどのように機能的に異なるかわかりません。
UPDATE：hg rebaseがサポートする--keepbranchesフラグを発見しました。すべてがokey-dokeyであると報告できてうれしいです。 hg rebase -d default --keepbranchesを使用して、求めていたGitの動作を正確に複製します。後にいくつかのエイリアスがあり、私は誰のビジネスのようにもリベースしていません。
すべてのすべてのイテレーションを維持することは良いと思うと言う人がいるので、大規模なオープンソースプロジェクトでは、マージと開発イテレーションでいっぱいの変更を受け入れると、メインラインの改訂履歴が乱雑になり、リビジョン履歴は、現在のバージョンがどのようにそこに到達したかを見るのにあまり役に立ちません。
これは、送信された変更が受け入れられる前に、それらを書いていない人によってレビューされたときにうまく機能します。その後、ラインのオリジンにバックトラックすると、それに伴うすべての変更が表示されますが、その一部である変更の開発の途中ではありません。
x265 contributors ページでは、作業中の一連の変更を再コミットして、送信準備を整える方法を説明しています。x265プロジェクトへ。 （コミット用のgit guiのstage/unstage diff hunkのように、個々のファイルのすべてではなく一部の変更をコミットするためのTortoiseHGの使用を含む）。
このプロセスでは、hgをアップストリームのヒントに更新してから、作業ディレクトリですべての変更をコミットせずに取得します。送信したいものの一部ではないものはすべて棚に入れ、残りはニースコミットメッセージで適切な数の個別のコミットに分割します。
修正するパッチセットの以前の反復からのコミットメッセージをコピーして貼り付けてから編集すると思います。または、古いコミット（git言語のチェリーピック）を移植し、それらを1つずつ修正して、古いコミットメッセージを編集の開始点として取得することもできます。