Mercurial：移植片対レコード対qrecord vs. shelve対移植対対流対待ち行列

Question

私はMercurialを初めて使用していますが、何とか評価プロセスにまだ入っていますので、これらの4つのコンセプトは私にとっては紛らわしいものです。 Gitのステージング/インデックスコンセプトと同等か、Gitのステージングより優れているものもあります。どのようにhg graft、hg record、hg qrecordとhg shelve 4つのコマンド（これはGraft vs. Transplantで説明されており、hg transplant、しかし、すでに）相互に比較して、どうやっキューの概念とdirstate？どちらのユースケースが選択されていますか？私はそれぞれのヘルプページがあることを知っていますが、一般的にVCSが私にとって新しいトピックであるため、それぞれが何をしているのか把握するのは難しいです。

Answer 1

Mercurialの設計にはステージング領域という概念は含まれていません。つまり、ローカルの変更とコミットの中間の状態はありません。ここで

はあなたが言及した概念のそれぞれの概要は次のとおりです。

hg graftはgit cherry-pickのと同じです。あるブランチから別のブランチにコミットをコピーします。この機能の典型的な使用例は、あるリリースブランチから別のリリースブランチにバグ修正をコピーすることです。このコマンドは、古い（そして今は廃止された）hg transplant拡張子を置き換えます。

hg recordおよびhg qrecordは、git add --patchと同様です。それらは、対話的にコミットのためにハンクを選択することを可能にします。したがって、1つのファイルのいくつかの異なる領域を変更した場合は、実際にコミットしたい領域（つまり、ハンク）を選択し、ローカルの変更として残したい領域を選択できます。

qrecordは、mqが有効な場合にのみ利用できます。それは標準コミットではなくmqパッチにコミットします。

hg shelveは、git stashと同様です。これにより、一時的にファイル（またはファイルのハンク）のローカル変更を脇に置くことができます。これらの変更は、準備ができたらunshelvedになります。

dirstateは、Mercurialソースコードの内部クラスです。ユーザーには公開されません。

Mercurial Queues（mqとしても知られています）はおそらく、Mercurialのステージング領域に最も近いでしょう。以下はMercurial wikiの説明です：

変更はMercurialにコミットされるパッチとして維持されます。 コミットを削除または並べ替えることができ、作業ディレクトリの変更に基づいて、基礎となるパッチを に更新することができます。パッチ ディレクトリもリビジョン管理下に置くことができるので、パッチに加えられた変更の履歴を個別に にすることができます。

mqは、ローカルでテストしているがパブリックな場所にプッシュしていないコミット/リワークによく使用されます。また、サードパーティ製のコードを変更するために、それを使用する人もいます。