これは、
Hg Initシリーズの4回目の記事であるJoel Spolsky
Mercurial Tutorialです。 前のパーツ：
Mercurialの主な利点の1つは、個人リポジトリのクローンを使用して、新しい機能を実験および開発できることです。 問題が発生した場合は、すぐに修正できます。
パート4.エラーの修正
Mercurialを使用すると、自由に実験できます。 作業中にエディターで何か間違ったことをし、ひどいことが起こったと想像してください。
Emacs、どうやってあなたを愛しているか。 それはそうかもしれないが、すべてを修正できる。 このような問題に対処する最も一般的な方法は、
hg revertコマンドを使用する
hg revertです。
hg revert
ファイルをリポジトリで修正された状態に戻します。
このコマンドは、ファイルを最後のコミット時の状態に正確に戻します。 Mercurialは何も削除したくないので、
豚のラテン語でレシピを上書きする代わりに、ファイルの名前を変更しました。
しかし、すべてが行き過ぎて、すでにコミットしている場合はどうでしょうか？
誤ったコミットを別のリポジトリにプッシュしていない場合のみ、スキンを保存する
hg rollbackコマンドがあります。 このコマンドは、
1つのコミットをキャンセルします。
hg rollback
別のリポジトリにプッシュしていない限り、1つのコミットをキャンセルします。
暇なときに素晴らしい実験をしたいと想像してください。 あなたの上司は新しいデザイナー、ジムを雇いました。 それ以来、あなたが得るデザインは単純に不合理になりました。 それらは酸性の緑色のテキストを持ち、何も整列されていません（そのための「芸術的な」理由があります）、使いやすさは不十分です。 あなたは週末に仕事に来てすべてをやり直したいと思っていますが、あなたのアイデアがこのクレイジーなデザイナーよりも優れていることを100％確信していないため、変更をコミットすることを恐れています。 ジムは、目覚めてから寝るまでのほとんどの時間草を吸っています。 あなたは彼に対してそれを使用したくありません、そして、誰もが、この習慣はデザインが秩序である限り誰にも関係しないと考えています。 しかし、すべてに制限があります。 そう？ そしてジムのデザインは故障しており、一般的に彼は一種の厚かましいです。
Mercurialを使用する場合、リポジトリ全体のクローンを簡単に作成できます。
これは見た目ほど無駄ではありません。
レシピと
レシピ実験リポジトリは同じものを保存しているため（現時点では）、Mercurialはハードリンクを使用します。 これは、リポジトリのコピーが迅速に作成され、追加のディスク容量を占有しないことを意味します。
これで、実験ブランチでいくつかの変更を行うことができます。
私の素晴らしいワカモレ実験を始めましょう：
恐れることなく実験的なリポジトリにコミットできます：
安全に変更を加えることができ、いつでも結果を修正できます。 これにより、狂った実験でもバージョン管理のすべての力が得られ、誰も傷つくことはありません。
実験が失敗したと判断した場合は、実験リポジトリを使用してディレクトリ全体を単純に削除できます。 リポジトリなし-問題ありません。
しかし、すべてがうまくいった場合は、新しい編集をプッシュするだけです。
そして、彼らはどこを通り抜けましたか？
hg paths
既知のリモートリポジトリのリストを表示します。
「デフォルト」で始まる行には、リポジトリへのパスが含まれます。別のリポジトリを明示的に指定しない限り、
hg pushは変更を
hg pushます。 通常、この行には、クローンを作成したリポジトリへのパスが表示されます。 この場合、これはローカルディレクトリですが、パスはURLにすることもできます。
この
リポジトリに変更をプッシュすることを忘れないでください
...
...は、作業ディレクトリに変更を表示しません。
hg parent
作業ディレクトリにある一連の変更を表示します。
ほら 変更の5番目のセットでQuesoについて編集します。 しかし、私のメインリポジトリでは、4番目の変更セットで作業が停止しました。 誰かが
リポジトリに変更をプッシュしたという事実から、作業ディレクトリは更新されず、変更の5番目のセットはそこに表示されませんでした。 そのため、私はまだ4番目の変更セットを使用しています。
5番目の変更セットの内容を知りたい場合は、
hg updateコマンドを使用する必要があります。
何が起こったの？ 変更は受け取られましたが、それらは私が使用したバージョンの後にありました。
pushおよび
pullコマンドは、リポジトリ間で変更を
pushするだけです。 これらのコマンドは、現在作業しているものには影響しません。
リポジトリは次のようになります。
Mercurialは、リポジトリからリポジトリに変更をプッシュする方法に柔軟性があります。 実験版から中央リポジトリに直接変更をプッシュできます。
そのため、5番目の変更セットは、実験的なものから中央リポジトリに送信されました。 ここで、メインリポジトリに戻ると、これ以上プッシュするものがないことがわかります。
これは、Mercurialが中央リポジトリのこの（5番目の）変更セットがすでにどこかからのものであることを知っているためです。 そうしないと、Mercurialが変更を再度適用しようとする可能性があり、深刻に混乱する可能性があるため、これは非常に便利です。
デザイナーのジムは、仕事を提供された後、すぐに仕事に取り掛かることを約束しました。 しかし、彼はさらに2か月間職場に現れませんでした。 ほとんど誰もが彼について、そして彼らが彼に仕事を提供したという事実についてすでに忘れているので、彼がオフィスで初めて日焼けしたとき、正直に言うと、誰が彼が誰で何が起こっているのかを本当に理解できませんでした。 それは十分面白かった。 彼の外観は典型的です。 結局、彼らはそれをすべて理解しましたが、彼は新しいので、誰も彼に一体何が起こったのかと尋ねることに恥ずかしがりました。 また、顔の傷や打撲についても尋ねられませんでした。 関係ありません。 この男が嫌いです。
数か月後、あなたは間違いを犯していることに気付くことがあります。
ポテトチップス？ なに..？！
Mercurialは、古い変更セットを履歴から削除する場合があります。 Mercurialは一連の変更を確認し、逆のアクションを決定し、現在の作業ディレクトリを変更します。 古いリビジョン番号2を削除してみましょう。
神の母、それは何でしたか？
一般的に言えば、多くの時間が経過する可能性があります。 チップは一般的にレシピから消える可能性があります。 多くの不気味なことが起こり得ます。 そのため、リビジョンが削除された後、変更を結合することができない場合があります。 このような場合、マージの競合が発生するため、何らかの方法で解決する必要があります。 これは次のパートで説明します。
自分でテストする
このパートを読んだ後にできることは次のとおりです。
- ランダムな変更をロールバックします。 リポジトリにコミットされる前と後。
- 実験のためにリポジトリをローカルにクローンします。
- 変更を異なるリポジトリにプッシュします。
- かなり前にリポジトリで修正された古いエラーをロールバックします。
ここに続きます：
Hg Init：パート5.マージプロセス