最も一般的なMercurialコマンドのGit相当物？
Mercurialを使用していますが、Gitの簡単なデモを行いたいです。
Gitに相当するものは何ですか：
hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?
そこで言及されていない2つの間にいくつかの落とし穴があります。このリストは、他の方法（git-> hg）で行ったときに自分のブログ投稿から引用したものです。
Hg.hgignore、構文：globはgitの.gitignoreと同じ動作です。
Git.git/config、〜/ .gitconfig、git-configを使用して値を変更する
Hg.hg/hgrc、〜/ .hgrc、hg help -c configを使用
Gitgit commit -v
Hghg diff |もっと少なく; hg commit
Gitgitk
Hghgビュー、または TortoiseHg からのthg
Gitgit gui
HgMercurialは、チェンジセットを選択するためのGUIを出荷していません。コンソールhg recordコマンドのみです。
Gitgit rebase
Hghg rebase 。 git rebase --interactiveには hg histedit 、またはMercurialキューがあります
Gitgit Push URL; git remote add Origin URL
Hghg Push URL; $ EDITOR .hg/hgrc; [パス]デフォルト= URL
Gitgitk、git log Origin/master..HEAD
Hghg発信
Gitgit format-patch RANGE
Hghg email -m filename -o
Gitgit add。 ;ドットに注意してください
Hghg add;ドットは必要ありません。
Gitgit checkout REVISION-KEY
Hghg update CHANGESET
空白を埋めるだけで、Mercurialの最も便利なコマンドの一部は次のとおりです。
Hghgレコード
Gitgit add -p; git commit
Hghg inc [URL]
Git同等の機能はありませんhg pull; hg log -r .:と同等のことしかできません
Hghg out URL
Git方法がわかっている場合は追加してください。
マージの競合解決のために、Mercurialのhg resolveコマンドには、動作を変更するいくつかのオプションがあります。
Hghg resolve -m FILE（競合の問題を手動で修正することにより、ファイルが解決済みとしてマークされます）
Gitgit add FILE
Hghg resolve -u FILEは、ファイルを未解決としてマークします
Gitgit reset HEAD FILEはファイルのステージングを解除します
Hghg resolve -l（競合の解決/未解決のファイルをリストします）
Gitgit status-きれいにマージされたファイルは自動的にインデックスに追加され、競合のないファイル
Hghg resolve FILE（マージ後、ファイルの再マージを試みます）
Git私が知っている再マージに相当するものはありません。
注：GitとMercurialの最大の違いの1つは、indexまたはstaging areaが明示的に存在することです。
Gitは唯一の DistributedSCM であり、インデックスまたはステージング領域の概念を公開します。他の人はそれを実装したり隠したりするかもしれませんが、他の場合にはユーザーは気づかないし、対処する必要もありません。
Mercurialのおおよその同等物は
DirStateです。これは、作業コピーのステータス情報を制御して、次のコミットに含めるファイルを決定します。ただし、いずれにしても、このファイルは自動的に処理されます。
さらに、コマンドラインでコミットするファイルを指定するか、RecordExtensionを使用することで、コミット時により選択的にすることができます。あなたがインデックスを扱うことに不快感を感じた場合、あなたはより良い方向に切り替えています;-)
秘Theは、Gitを完全に活用するにはインデックスを本当に理解する必要があるということです。このように 2006年5月からの記事 はそのとき私たちに思い出させます（そしてそれは今でも真実です）：
「インデックスを拒否すると、git自体を本当に拒否します。」
現在、その記事には多くのコマンドが含まれていますが、これらのコマンドはより簡単に使用できるようになりました（その内容にあまり依存しないでください;））
新しい機能に取り組んでおり、ファイルに小さな変更を加え始めています。
# working, add a few lines
$ git add myFile
# working, another minor modification
$ git add myFile
この時点で、次のコミットは現在のブランチに2つの小さな変更を加えます。
# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work
$ git commit
この時点でステージング領域（インデックス）に追加された変更のみを記録し、作業ディレクトリに現在表示されている主要な変更は記録しません。
$ git branch newFeature_Branch
$ git add myFile
次のコミットは、新しいブランチ「newFrature_Branch」のその他すべての主要な変更を記録します。
現在、Mercurialでは、 'hg record'コマンドまたはその他の拡張機能を使用して、インタラクティブに追加するか、コミットを分割することもできます。 RecordExtension をインストールする必要があります。 CrecordExtension 。
ただし、これはMercurialの通常のワークフローの一部ではありません。
Gitはコミットを一連の「file contentchanges」と見なし、それらの変更を1つずつ追加できます。
この機能とその結果を検討する必要があります。Gitのパワーの大部分（簡単に マージを元に戻す（または問題を二分する、コミットを元に戻す）など 、 Mercurialに反して ）は、その「ファイルコンテンツ」パラダイムに由来します。
tonfa （プロファイル内：「Hg dev、pythonist」：数字...）コメントで：
インデックスには基本的に「git-ish」はありません。hgは、価値があると思われる場合はインデックスを使用できます。実際、
mqまたはshelveはすでにその一部をしています。
ああ少年。ああ、またか。
まず、あるツールを別のツールよりも見栄えよくするためにここにいるわけではありません。 Hgは非常に直感的で、優れたサポートが得られます（特にLinux、Solaris8または10でも動作しますが、メインプラットフォームであるWindowsで）。
インデックスは実際には前と中央にあります Linus TorvaldsはVCSで動作します ：
Gitは、最初のマージを行う前であっても、1日目からの明示的なインデックス更新を使用しました。それは私がいつも働いてきた方法です。私は、次のバージョンの単なるMakefile更新であるため、ツリーにランダムなパッチがいくつかありますnotコミットしたいので、汚れたツリーを持っている傾向があります
インデックスのcombination（Gitでのみ見られる概念ではありません）、and「コンテンツは王様」のパラダイムがそれを作ります- かなりユニークで「git-ish」 ：
gitはcontent trackerであり、ファイル名はそのコンテンツに関連付けられていない限り意味がありません。したがって、git add filenameの唯一の正常な動作は、ファイルのコンテンツとその名前をインデックスに追加することです。
Gitのインデックスは基本的に非常に定義されています
- ツリーの合計「content」を含むのに十分です（そして、このはすべてのメタデータを含む：ファイル名、モード、およびファイル内容はすべて「コンテンツ」のpartsであり、それ自体はすべて意味がありません！）
- 明らかで些細な（しかし非常に重要な）ファイルシステム比較の最適化を可能にする追加の「統計」情報。
したがって、をインデックスとしてbeing thecontentとして参照する必要があります。
コンテンツは、個別の部分としての「ファイル名」または「ファイルコンテンツ」ではありません。本当に2つを分けることはできません。
ファイル名だけでは意味がありません（ファイルコンテンツも必要です）。また、ファイルコンテンツ自体も同様に無意味です（到達方法を知っている必要があります）。私が言おうとしているのは、gitが基本的にallowでなく、コンテンツのないファイル名を見ることです。概念全体は狂気であり、無効です。 「現実」とは関係ありません。
FAQ から、主な利点は次のとおりです。
- 細かい粒度でコミットする
- かなり長い間、コミットされていない変更をツリーに保持するのに役立ちます
- 1つのコミットに対していくつかの小さなステップを実行し、
git diffで行ったことを確認し、各小さなステップをgit addまたはgit add -uで検証します。 - マージ競合の優れた管理を可能にします：
git diff --base、git diff --ours、git diff --theirs。 - インデックスがその間に変更されていない場合、
git commit --amendがログメッセージのみを修正することを許可します
私は個人的に、この動作をデフォルトにすべきではないと考えています。テストされているか、少なくともコンパイルされている何かを人々にコミットしてほしい
一般に（「テスト済みまたはコンパイル済み」部分について）、Gitがブランチとマージ（チェリーピッキングまたはリベース）を許可する方法により、一時的なプライベートブランチ（プッシュのみ）で何度でもコミットできます。リモートの「バックアップ」リポジトリへ）、すべての適切なテストが適切に行われている状態で、パブリックブランチでそれらの「ugいコミット」を再実行します。
マーキュリアル：
hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?
Gitの同等物：
git init
git add -A
git commit -am "comment" # -a is not necessary along with the above add -A
git status
Addremoveを使用しない場合とほぼ同じです。
git init # Start a project in the current directory
git status # Displays both changes and added/removed files
git commit -m "comment" # commit any uncommited changes
ただし、これらは単独で作業するときに使用するコマンドです。 git pullおよびgit Push、および関連するコマンドを使用して、変更を他の人の作業とマージしたい場合は、neatになります。