Hg Init:パート2:Mercurialの基本

これは、 Hg Initシリーズの第2部 Joel Spolsky Mercurial Tutorialです。 Subversionユーザー向けの再トレーニングの最初の部分もお読みください。

単独で作業する場合でも、Mercurialを使用する必要があります。 したがって、バージョン管理の魅力をすべて得ることができます。 このパートでは、Mercurialにディレクトリを追加して、以前のバージョンを簡単に追跡することがいかに簡単かを示します。

パート2. Mercurialの基本



Mercurialはバージョン管理システムです。 開発者はこれを使用してソースコードを管理します。 彼女には2つの主な目的があります。
  1. 各ファイルの以前のバージョンをすべて保存します。
  2. コードのさまざまなバージョンを組み合わせることができます。つまり、従業員は独立してコードを操作し、変更をマージできます。




Mercurialを使用しない場合、次のコードを使用してディレクトリのコピーを多数作成するだけで、以前のバージョンを保持することができます。



退屈で、多くのディスク容量を必要とし、混乱を招きます。 バージョン管理システムを使用することをお勧めします。

ほとんどの人は、コマンドラインインターフェイスを介してMercurialを操作します。 これは、Windows、Unix、およびMacで実行できます。 Mercurialのコマンドはhgです。



パラメータなしでhgを実行すると、最も頻繁に使用されるコマンドのリストが表示されます。 hg helpを試して、コマンドの完全なリストを取得することもできます。

バージョン管理を利用するには、 リポジトリが必要です 。 リポジトリには、すべてのファイルの以前のバージョンがすべて保存されます。 実際、ディスク容量を節約するために、以前のバージョンはすべて保存されず、変更のコンパクトなリストのみが保存されます。

昔は、リポジトリを持つことは大したことでした。 中央サーバーが必要で、そこにソフトウェアをインストールする必要がありました。 Mercurialは分散システムなので、派手な中央サーバーなしで使用できます。 コンピュータのみを使用してMercurialを使用できます。 リポジトリの取得は非常に簡単です。コードを使用してディレクトリに移動するだけです...



...そして、 hg initコマンドを実行しhg init



hg init
リポジトリを作成します。


ちょっと待って、何かあったの? 何も変わっていないようです。 いいえ、よく見えると、新しい.hgディレクトリが表示されていることがわかります。



これがリポジトリです! これは、Mercurialが機能するために必要なすべてのディレクトリです。 設定、以前のバージョンのファイル、タグ、雨の場合の追加の靴下など。 そこに登らないでください。 ほとんどの場合、自分でこのディレクトリを使用する必要はありません。

さて、これで焼きたてのリポジトリができたので、そこにすべてのソースファイルを追加します。 これも簡単です: hg addを実行するだけです。



hg add
リポジトリに追加される予定のファイルをマークします。 変更をコミットするまで、ファイルは実際には追加されません。


もう1つ手順があります... 変更コミットする必要があります 。 何が変わりますか? これらすべてのファイルを追加するという事実。

なぜ変更をコミットせざるを得ないのですか? Mercurialを使用する場合、変更をコミットするとは、「これがファイルの外観です。覚えておいてください」という意味です。 これは、カタログ全体のコピーを作成するようなものです。何か変更するたびに、好きなときに変更をコミットします。

hg commit
すべてのファイルの現在の状態をリポジトリに保存します。




Mercurialはエディタを起動し、変更に関するコメントを印刷できるようにします。 行った変更を思い出させるために何かを書く必要があります。



エディターを保存して終了すると、変更がコミットされます。

hg logを実行して、変更履歴を表示できます。 これは、リポジトリのブログのようなものです。



hg log
リポジトリにコミットされた変更の履歴を表示します。


ファイルを変更して、何が起こるか見てみましょう。



変更を行ったので、 hg commitを使用してコミットできます。



Mercurialは、1つのファイルa.txtのみが変更されたと推測したことに注意してください。



そして今、コミット(変更をコミット)した後、ストーリーを見てみましょう。



現在のブロガーと同様に、Mercurialは最新のものを最初に配置します。

私は自分自身を楽しませるために、別の変更を加えるつもりです。



コミット(変更のコミット):



私のコミットメッセージ:



そして今、歴史に何がありますか?



まあ、それは楽しかったです。 私はいくつかの変更を行い、重要な変更を行うたびにリポジトリにコミットしました。

私は知っている、あなたは今考えている:「ジョエル、これはすべて廃棄物廃棄時間を見ている。」 なぜこのカタバシヤすべてがコミットされているのですか?

忍耐、私の若い友人。 このすべてを活用する方法を学習しようとしています。

まず、編集プロセスで大きな間違いを犯したとしましょう。



そして、私の良さ、すべてに加えて、あなたはいくつかの非常に重要なファイルを削除しました。



Mercurialがなかった時代には、これらすべてがシステム管理者に行く良い理由になる可能性がありました。 そこで、あなたの目に涙を浮かべて、あなたは彼に鋭く悲しい質問をするでしょう:「なぜバックアップシステム」は一時的に「過去8ヶ月間機能しない」。

Tacoという名前のシステム管理者は控えめすぎて、チームの他のメンバーと食事をしません。 彼が車椅子に座っていないまれなケースでは、三角形のサルサ色のスポットがあり、そこから彼の足から落ちた水滴、メキシコのお菓子から落ちた水滴が見えます。 これらのドロップは、誰も彼の椅子を持っていないことを保証しますが、これはハーマンミラーの優れた椅子の1つで 、会社の創業者が愛する人のために購入したものであり、誰もが背中を痛めている通常の予算事務所のものではありません。

いずれにしても、バックアップはありません。

Mercurialのおかげで、自分のしたことが気に入らない場合は、便利なhg revertコマンドを実行できます。これにより、ディレクトリは最後のコミット時の状態に即座に戻ります。



hg revert
変更されたファイルをリポジトリに固定されたビューに戻します。


すべてのファイルを以前の状態に戻したいため、-- all引数を使用しました。

したがって、Mercurialを使用してソースコードを操作する場合、次のことを行います。
  1. 変更を加える
  2. 適合するかどうかを評価する
  3. 必要に応じて、 commit
  4. 適切でない場合は、 revert
  5. 後藤1


(私は知っています。Windowsでコマンドラインを使用し、GOTO演算子を使用します-私はこれまで住んでいた中で最悪のプログラマです。)

時間が経つと、最後にコミットしてから何が停止し、何が変わったかを忘れることができます。 Mercurialはこれらすべてを追跡します。 hg statusを実行するだけで、Mercurialは変更されたファイルのリストを提供します。

hg status
変更されたファイルのリストを表示します。


1つのファイルを作成し、別のファイルを編集し、3番目のファイルを削除したとします。



hg statusは、各行の先頭にアイコンを追加することにより、変更されたファイルのリストを表示します。 このアイコンは何が起こったかを示しています。 「M」は「変更」を意味します-ファイルは変更されています。 「!」 いいえ-ファイルはここにあるはずですが、どこかに行ってしまったことを意味します。 「?」 状態が未定義であることを意味します-Mercurialはこのファイルについて何も知りません。 まだわかりません。

変更を1つずつ処理しましょう。 a.txtファイルの変更点は次のとおりです。 変更したことを忘れることができます。 地獄、私は私が朝食のために通常食べるものをかろうじて覚えています。 そして、これらが常にCHEERIOSクリスピーリングであることが特に心配です。 いずれにしても、a.txtは変更されます。 何が変わった?

このためのコマンドがありますhg diffは、最後のコミットからファイルに何が起こったかを正確に知らせます。

hg diff
ファイルの変更点を示します。




結果の形式は少しわかりにくいですが、最も重要なのは、マイナスで始まる行(これが削除されたもの)とプラスで始まる行(これが追加されたもの)を確認できることです。 したがって、「普通の人」が「市民」に置き換えられていることがわかります。

次に、不足しているfavicon.icoファイルについて説明します。 既に述べたように、本当に削除する予定がない場合は、 hg revertコマンドを実行して復元できます。 しかし、本当に削除したいとします。 ファイルを削除(または追加)するたびに、このMercurialイベントを報告する必要があります。

hg remove
リポジトリからの削除がスケジュールされているファイルをマークします。 ディスク上のファイルは、変更をコミットするまで削除されません。




「R」は「削除済み」、つまり削除のマークが付いていることを意味します。 次のコミット時に、Mercurialはこのファイルを削除します。 (このファイルの履歴はリポジトリに保存されるため、もちろんいつでも元に戻すことができます。)最後に、この新しいb.txtファイルを追加する必要があります。



「A」は「追加」を意味します。つまり、追加のマークが付いています。 私は毎回hg statusを書くのが面倒だったことに気付きましたか? Mercurialの場合、コマンドを一意に定義する最小限の文字セットで十分であり、 st開始するコマンドは1つだけです。

質問と感嘆符を整理したら、続行して変更を加えることができます。



hg logの出力で他に注意する価値があるのは、変更セットの行に各コミットの数が表示されることです。 実際、2つの数字さえあります。最初のリビジョンの「0」のような短い便利な数字と、今は無視できる長い理解できない16進数です。

Mercurialは、任意のファイルの任意のバージョンを再作成するのに十分な情報をリポジトリに保存することに注意してください。

まず、単純なhg catを使用して、任意のファイルの任意のバージョンの内容をコンソールに出力できます。 たとえば、a.txtファイルの内容を確認する方法は次のとおりです。



hg cat
リビジョンのファイルの内容を表示します。


以前のファイルの外観を確認するために、 -r引数(「リビジョン」、つまりリビジョン)を使用して、変更セット(ログからの変更セット)の数を指定するだけです。



ファイルに複雑なコンテンツまたは大きな長さがあり、わずかにしか変更されていない場合、引数rを指定してhg diffを使用して、2つのリビジョンの違いを表示できます。 たとえば、リビジョン0と1の違いを確認する方法は次のとおりです。



そして最後に、-あなたがまだ疲労から脱落していないことを願っています-このパートを終える前に、もう1つの小さなトリックを示したいと思います: hg updateコマンドで、リビジョンを作成する時間に前後に移動できます。 まあ、 本質的に 、あなたは未来に移動することはできません。 リビジョンが4つしかない場合、 hg update -r 103994を実行して、ソースの本当にクールなバージョンを取得できます。 グラビサポイと他の未来的なもの。 しかし、もちろんこれは不可能です。

実際に可能なのは、任意のリビジョンに戻ることです。 あなたの手を見てください:



hg update
作業ディレクトリを特定のリビジョンのような状態にします。


実際、リビジョン間を行き来するために、 hg updateはファイルに記憶された変更を加えます。 ファイルが追加または削除された場合、このコマンドはディスクにファイルを追加または削除します。 パラメータを追加せずにhg updateを実行hg update 、作業ディレクトリが最新リビジョンのような状態になります。

自分でテストする


いいね! これで終わりです。 現時点でできることは次のとおりです。
  1. リポジトリを作成する
  2. リポジトリからファイルを追加または削除します
  3. 変更を行った後、行われたことを確認してから
  4. ...必要に応じて変更をコミットする
  5. ...または、気に入らない場合は変更をロールバックします
  6. ファイルの以前のバージョンを表示するか、作業ディレクトリをあるリビジョンのような状態にします。


ここに続きます:
Hg Init:パート3.チームでの作業に慣れる

Source: https://habr.com/ru/post/J108658/


All Articles