私はプロジェクトのために Mercurial をローカルで使用しています (他の場所へのプッシュ/プルがない唯一のレポです)。
今日まで、それは直線的な歴史を持っています。しかし、私が現在取り組んでいることはひどいアプローチであることに気づきました。開始する前のバージョンに戻って、別の方法で実装したいと考えています。
Mercurial の // コマンドについてbranch少し混乱していrevertます。update -C基本的に、バージョン 38 (現在は 45) に戻し、次のコミットでは 38 を親として、そこから続行したいと考えています。リビジョン 39 ～ 45 が永久に失われたり、独自の行き止まりのブランチになってしまったりしても、私は気にしません。
どのコマンドまたはコマンド セットが必要ですか?
コマンドのチートシートは次のとおりです。
hg update作業コピーの親リビジョンを変更し、ファイルの内容もこの新しい親リビジョンに一致するように変更します。これは、更新先のリビジョンから新しいコミットが引き継がれることを意味します。
hg revertファイルの内容のみを変更し、作業コピーの親リビジョンはそのままにします。通常hg revert、作業コピー内のファイルに対して行ったコミットされていない変更を保持したくない場合に使用します。
hg branch新しい名前付きブランチを開始します。名前付きブランチは、変更セットに割り当てるラベルと考えてください。そうすればhg branch red、次のチェンジセットは「赤い」ブランチに属するものとしてマークされます。これは、チェンジセットを整理するのに便利な方法です。特に、さまざまな人がさまざまなブランチで作業していて、後でチェンジセットの作成元を確認したい場合に便利です。しかし、あなたの状況ではそれを使用したくありません。
を使用するhg update --rev 38と、変更セット 39 ～ 45 が行き止まり (いわゆるぶら下がった頭) として残されます。プッシュ先のリポジトリに「複数のヘッド」を作成するため、プッシュすると警告が表示されます。誰かがマージを行う必要があることを示唆しているため、そのような頭を残すのは一種の無礼であるため、警告があります。しかし、あなたの場合は、先に進むことができhg push --forceます。本当にそれをぶら下げたままにしたいからです。
リビジョン 39-45 をまだどこかにプッシュしていない場合は、それらを非公開にしておくことができます。それは非常に簡単です:hg clone --rev 38 foo foo-38リビジョン 38 までしか含まない新しいローカル クローンを取得します。作業を続けて、foo-38作成した新しい (良い) 変更セットをプッシュできます。fooクローンには古い (悪い) リビジョンがまだ残っています。(クローンの名前は自由に変更できます。たとえば、footofoo-badやfoo-38tofooなど)。
最後に、使用hg revert --all --rev 38してコミットすることもできます。これにより、リビジョン 38 と同じように見えるリビジョン 46 が作成されます。その後、リビジョン 46 から作業を続行します。これにより、履歴に分岐が作成されたのと同じ明示的な方法で作成されるhg updateことはありませんが、一方で、複数の頭。hg revertリビジョン 45 に基づいて既に独自の作業を行っている他のユーザーと共同作業を行う場合に使用します。それ以外の場合hg updateは、より明示的です。
hg update [-r REV]
後でコミットすると、効果的に新しいブランチが作成されます。その後、このブランチのみで作業を続けるか、最終的に既存のブランチをマージすることができます。
commit と push を行った直後に、1 つのファイルだけを以前のリビジョンに戻す必要がある場合に遭遇しました。これらのリビジョンを指定するための簡略構文は、他の回答ではカバーされていないため、これを行うコマンドを次に示します。
hg revert path/to/file -r-2
これ-2は、最後のコミットの前のバージョンに-1戻ります。使用すると、現在のコミットされていない変更が元に戻ります。
上記の回答は最も役に立ち、多くのことを学びました。ただし、私のニーズに対する簡潔な答えは次のとおりです。
hg revert --all --rev ${1}
hg commit -m "Restoring branch ${1} as default"
ここ${1}で、リビジョンの番号またはブランチの名前です。これらの 2 つの行は、実際には bash スクリプトの一部ですが、手動で実行する場合は単独で問題なく動作します。
これは、ホット フィックスをリリース ブランチに追加する必要があるが、デフォルトからビルドする必要がある場合に役立ちます (CI ツールを正しく取得し、ブランチからビルドできるようになり、後でリリース ブランチも廃止するまで)。