1

私は今日、私の最初の水銀問題に直面しました。私は自分のリポジトリにいて、ファイルを変更して、

hg commit
hg pull

続いてhgupdatehgロールバック

私が行ったことを修復するために（しかし実際には何もプッシュしませんでした）問題は、プルを実行したときに（コミット前に実行する必要があるため、ヘッドが変更されたため、hgヘッドは次のようになります）です。

- Modif from yesterday
- My modif
- Modif from last week

そして今、誰かが（httpインターフェースを介して）別の変更を行ったことがわかります。ローカルリポジトリを修復し（可能であればサマリーを変更して）、他の2つの変更の後にプッシュするにはどうすればよいですか。

どうもありがとう。静かな混乱、私の「一人」のリポジトリでは簡単でした。

4

1 に答える 1

3

ローカルリポジトリは「修復」する必要はありません。これは非常に標準的なケースであり、Mercurialを頻繁に使用する場合によく見られます。

問題は複数の頭です。

作業ディレクトリが自分のバージョンであり、他のヘッドしかない場合は、ヘッドをマージできます。

hg merge

これにより、変更セットがマージされます（ブランチ間でマージする場合と同じです）。

または、リベース拡張機能を有効にして、バージョンをブランチの先端（もう一方のヘッド）にリベースすることもできます。

hg rebase --source<YourVersionNumber> --dest<TipVersionNumber>

これにより、変更セットがマージされることはなく、指定した変更セットの上に変更を移植するだけで、あたかもその変更セットから生まれたかのようになります（したがって、リベースまたは「新しい」ベース）。

複数のヘッドは面白い種類の内部ブランチ分岐です...自分のヘッドに対してチェックインを続け、を使用してヘッドを切り替えることができますhg update。サーバー上のブランチごとに複数のヘッドをブロックするため、プッシュは失敗します。複数のヘッドはブランチよりも明確ではないため、ローカルに保持することをお勧めします。

私はMercurialを次の2つの方法のいずれかで使用する傾向があります。

  1. 作業の規模が大きい場合は、それを分岐して継続的インテグレーションのプラクティスに従います（メインブランチを常に自分のブランチにマージするなど）。その後、最終結果に満足したら、メインに再度マージします。
  2. 作業の規模が小さい場合は、メインブランチに対して単純に作業し、ヘッドを「マージ」することがよくあります。私は通常リベースを使用するので、「マージ」と言います。変更が単純で、競合が発生する可能性が低い場合、リベースはうまく機能します。

私の厳格なルール：リベースを使用できない場合は、メインから生まれたブランチに配置します。

于 2012-04-24T10:27:16.150 に答える