210

Git では、次のことができます。

1. 新機能の作業を開始します。
$ git co -b newfeature-123 # (ローカル機能開発ブランチ)
いくつかのコミットを行います (M、N、O)

マスターA---B---C
                \
newfeature-123 M---N---O

2. アップストリーム マスターから新しい変更をプルします。
$ git プル
(ff-commits で更新されたマスター)

マスター A---B---C---D---E---F
                \
newfeature-123 M---N---O

3. マスターからリベースして、新しいフィーチャーを
アップストリームの最新の変更に対して開発できます。
(newfeature-123 より)
$ git リベース マスター

マスター A---B---C---D---E---F
                            \
newfeature-123 M---N---O


Mercurial で同じことを行う方法を知りたいのですが、答えを求めて Web を精査しましたが、見つけた最高のものは次のとおりでした: git rebase - can hg do that

そのリンクは2つの例を提供します：
1.これを認めます：（例のリビジョンを自分の例のリビジョンに置き換えます）

hg アップ -CF  
hg ブランチ -f newfeature-123  
hg 移植 -a -b newfeature-123

リベース前の MNO をマージされていないヘッドとして残し、更新されたメインラインから分岐することを表す 3 つの新しいコミット M'、N'、O' を作成することを除けば、それほど悪くはありません。

基本的に問題は、私がこれで終わることです：

マスター A---B---C---D---E---F
                \ \
newfeature-123 \ M'---N'---O'
                  \
newfeature-123 M---N---O

これは、削除する必要があるローカルの不要なコミットを残すため、良くありません。

  1. 同じリンクからの他のオプションは
hg qimport -r M:O
hg qpop -a
hg アップ F
hg ブランチ newfeature-123
hg qpush -a
hg qdel -r qbase:qtip

これにより、目的のグラフが得られます。

マスター A---B---C---D---E---F
                            \
newfeature-123 M---N---O

しかし、これらのコマンド (6 つすべて!) は、コマンドよりもはるかに複雑に見えます。

$ git リベース マスター

これが Hg の唯一の同等物なのか、それとも Git のような単純な他の方法があるのか​​知りたいです。

4

5 に答える 5

237

VonC には、探している答え、Rebase Extension があります。しかし、mercurial ではデフォルトで mq も rebase も有効にされていない理由について、1、2 秒考える価値があります。あなたが説明している方法で、ほぼ毎日仕事をしている場合、私がとるパターンは次のとおりです。

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

それだけで十分です。最終的に newfeature-123 のクローンが完成し、満足したらメインラインに簡単に戻すことができます。しかし、最も重要なことは、私が歴史を変えたことがないということです。誰かが私の csets を見て、それらが元々何に対してコーディングされていたか、そして私の仕事を通してメインラインの変更に私がどのように反応したかを知ることができます。誰もがそれが価値があると考えているわけではありませんが、ソース管理の仕事は、私たちが望んでいたことではなく、実際に何が起こったのかを示すことだと固く信じています。および他の履歴編集技術はそれを隠します。

ソープボックスを片付けている間に、VonCの答えを選んでください。:)

于 2010-04-20T04:14:15.697 に答える
105

RebaseExtensionを探している可能性があります。（SummerOfCode 2008の一部として実装されています）

このような場合、ローカルの変更を「デタッチ」し、リポジトリをメインストリームと同期してから、新しいリモートの変更の上にプライベートな変更を追加すると便利です。この操作はリベースと呼ばれます。

からの取得：

代替テキスト

に：

代替テキスト

steprobeによって以下にコメントされているように：

変更をプルしておらず、リポジトリに2つのブランチがある場合は、（を使用してkeepbranches）次の操作を実行できます。

hg up newfeature-123 
hg rebase -d master --keepbranches

（--keepbranches：元のブランチ名を継承します。）

Mojcaは次のように述べています。

を使うhg rebase --source {L1's-sha} --dest {R2's-sha}のは好きですが、最後に追加できるとは思いませんでし--keepbranchesた。

以下にジョナサン・ブラックバーンが示すように：

 hg rebase -d default --keepbranches
于 2010-04-20T03:57:25.987 に答える
44

最新のHgがインストールされていると仮定すると、次のように追加できます。

[extensions]
rebase =

〜/.hgrcに。

hg rebase次に、コマンド、、、hg pull --rebaseまたはを使用できますhg help rebase。

于 2010-04-20T04:02:34.727 に答える
3

一部の人々は、すべてのイテレーションを保持するのが良いと考えていると口を揃えて言っているので、大規模なオープンソース プロジェクトの場合、マージと開発のイテレーションに満ちた変更を受け入れると、メインラインの改訂履歴が乱雑になることを指摘しておきます。改訂履歴は、現在のバージョンがどのようにそこに到達したかを確認するのにはあまり役に立ちません。

これは、提出された変更が受け入れられる前に、それを書いていない人によってレビューされる場合にうまく機能します。次に、線の起点に戻ると、それに伴うすべての変更が表示されますが、それが含まれる変更の開発途中のポイントではありません。

x265 コントリビューターのページでは、作業中の一連の変更を再コミットして、x265 プロジェクトに提出する準備を整える方法について説明しています。(TortoiseHG を使用して、個々のファイルのすべてではなく一部の変更をコミットすることを含みます。たとえば、git gui のコミット用のステージ/アンステージ diff ハンクなどです)。

プロセスは、hg を上流のヒントに更新してから、作業ディレクトリですべての変更を未コミットにすることです。提出したいものの一部ではないものは棚上げしてから、残りを適切な数の個別のコミットに分割し、適切なコミット メッセージを付けます。

改訂中のパッチセットの以前の反復からコミット メッセージをコピーして貼り付けてから編集すると思います。または、古いコミットを移植して (git 言語でチェリーピック)、それらを 1 つずつ修正して、編集の開始点として古いコミット メッセージを取得することもできます。

于 2014-12-15T03:48:53.437 に答える