なぜMercurialはGitより簡単だと考えられていますか?


204

比較を見ると、機能セット間に1対1のマッピングが存在する可能性があるように思われます。しかし、よく引用される声明は、「Mercurialの方が簡単だ」というものです。この声明の根拠は何ですか?(もしあれば)


21
奇妙なことに、Mercurialの方が簡単だとは聞いていません。私はGitのドキュメントをさらに見つけました(おそらく認識されていたかもしれません)。
ニック

16
Linusが作ったからですか?
ジョブ

124
ここで神聖な戦争の領土に向かって進んでいますが、WindowsユーザーとしてMercurialに歓迎され、Gitのフリークと敗者のように扱われたため、Mercurialの方がGitより使いやすいことがわかりました。私はソフトウェアを擬人化しており、どちらもWindowsで問題なく使用できることを知っていますが、それは2人から得られた印象です。
Carson63000


11
Githubが存在しなかった場合、またはGithubにそれほど多くの有名なプロジェクトがなかった場合、Gitを使用する人はどれくらいいるのだろうか?
クリスS

回答:


240

適切な例:以前のすべてのコミットでユーザー名を変更するとします。さまざまな理由でこれを数回行う必要がありました。

Gitバージョン

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

Mercurialバージョン:

authors.convert.listファイル:

<oldname>=<newname>

コマンドライン:

hg convert --authors authors.convert.list SOURCE DEST

さて、どちらが使いやすいと思いますか?


注:私はGitだけで2年間働いていたので、これは「嫌い、2秒で手に入らなかった」という暴言ではありません。

私にとっては、使いやすさです。Gitは非常にLinux指向であり、Linuxの方法を使用しています。つまり、コマンドライン、マニュアルページ、および自分で理解することです。GUIが非常に貧弱でした(注:約1年前からこれをmsysGitに基づいています)。かろうじて使用できた

コマンドラインはさらに悪かった。Linux指向のプログラムであるため、Windowsでは使用が非常に困難でした。ネイティブポートの代わりに、MinGW(Think cygwin)でgitを単純にラップしたため、Gitでの作業がはるかに困難になりました。MinGWはWindowsコマンドプロンプトではなく、異なる動作をします。これがGitを使用する唯一の方法であることに夢中です。Linuxでさえ、まっすぐなコマンドラインで作業することが唯一の方法のように思えました。RabbitVCSのようなプロジェクトは一部を助けましたが、あまり強力ではありませんでした。

コマンドライン指向のアプローチとLinuxプログラムであるため、ほとんどすべてのハウツーガイド、ヘルプドキュメント、フォーラム/ QAの質問は上記のような巨大なコマンドの実行に依存していました。基本的なSCMコマンド(コミット、プル、プッシュ)はそれほど複雑ではありませんが、それ以上に複雑さが指数関数的に増大します。

また、多くのOSS gitユーザーがうろうろしている1つの場所、Githubも嫌いです。最初にgithubページにアクセスすると、できることは何でもできます。私にとって、プロジェクトのgitページは混oticとしていて恐ろしく、非常に強力に見えます。プロジェクトが何であるかの説明でさえ、下に押し下げられます。Githubは、完全なWebサイトが既にセットアップされていない人々を本当に傷つけます。その問題トラッカーもひどくて混乱しています。機能のオーバーロード。

Gitユーザーも非常にカルト的なようです。Gitユーザーは、常にDVCSの方が優れている「聖戦」を開始するユーザーであるように思われます。これにより、Mercurialユーザーは自己防衛を余儀なくされます。http://whygitisbetterthanx.com/のようなサイトは、ar慢さとほぼ「私のソフトウェアを使うか死ぬか」という考え方を示しています。多くの場合、Xを知らない、Xを事前に使用する、Windowsを使用するなどの理由でflame折するために、さまざまな支援の場所に行ってきました。


一方、Mercurialはより親切なアプローチに向かっているようです。彼らのホームページは、Gitのページよりも新しいユーザーにとってはるかに友好的です。単純なGoogle検索では、5番目の結果はTortoiseHgで、Mercurialの非常に優れたGUIです。彼らの全体的なアプローチは、最初はシンプルで、後は力になるようです。

Mercurialでは、SSHナンセンスはありません(WindowsではSSHは地獄です)、愚かな複雑なコマンドはありません。カルトユーザーはいません。Mercurialは機能します。

TortoiseHgは、実際に有用な機能を提供する実際に使用可能なインターフェースを提供します(最近は成長しているようですが)。オプションは必要なものに限定され、めったに使用されない混乱とオプションを取り除きます。また、多くの適切なデフォルトを提供します

Mercurialは、新規参入者に非常に親しみやすく、簡単に手に入れることができました。さまざまな分岐モデルや履歴編集など、より複雑なトピックのいくつかでも非常に簡単に理解できました。私はMercurialを迅速かつ無痛で手に入れました。

Mercurialは、セットアップがほとんどなくても初めて動作します。どのOSでも、TortoiseHgをインストールするだけで、さまざまなGuisを探す必要なく、必要なすべての機能(主にコンテキストメニューコマンド)を取得できます。また、SSHのセットアップもありません(ガイドの半分はPutty、Plink、およびPagentを使用すると言い、残りの半分はssh-keygenを使用すると言っています)。新規ユーザーの場合、TortoiseHgのセットアップには数分かかりますが、Gitは多くのグーグルで30分から1時間かかります。

最後に、オンラインリポジトリがあります。Githubに相当するのはBitBucketで、これには上記で説明した問題がいくつかあります。ただし、Google Codeもあります。Google Codeプロジェクトにアクセスすると機能のオーバーロードは発生せず、すっきりしたきれいなインターフェイスが表示されます。Google Codeは、オンラインリポジトリ/ウェブサイトのコンボのようなもので、既存のサイト設定がないOSSプロジェクトに本当に役立ちます。私は、かなり長い間、Google CodeをプロジェクトのWebサイトとして使用することに非常に満足し、絶対に必要な場合にのみWebサイトを構築します。その問題トラッカーも強力で、Githubのほとんど役に立たない問題トラッカーとBugzillaの怪物の間にうまく収まります。

Mercurialは、毎回初めて動作します。Gitは邪魔になり、使用するほど怒ります。


6
コメント者:コメントは明確な説明を求めるためのものであり、詳細な議論のためではありません。解決策がある場合は、答えを残してください。ソリューションが既に投稿されている場合は、投票してください。他の人とこの質問について話し合いたい場合は、チャットを使用してください。詳細については、FAQを参照してください

1
IntelliJ IDEAとXcode 4は、それぞれのプラットフォームでGitと素晴らしい統合があり、日々のタスクではコマンドラインを使用する必要はありません。

4
WindowsでGITを使用する場合、tortoiseGITの方がはるかに優れていることを付け加えます。SSLキーを処理する必要があり、インストールプロセスはスムーズではありませんが、完了すると簡単に機能します。
アルク

2
Git拡張機能個人的には、WindowsでTortoiseHGよりも操作や操作がはるかに簡単だと感じています。また、gitで使用したコマンドラインは1つだけです。
KallDrexx

1
「MinGWはWindowsコマンドプロンプトではなく、単に異なる動作をします。これがGitを使用する唯一の方法であるのはクレイジーです。」Windowsコマンドラインから実行するには、msysgitインストールとオプション2を使用します。正常に動作します。機能しないもの(キャレット、DOSの行継続文字など)がいくつかありますが、正常に機能するもの(チルダなど)に代わるものがあります。私はコマンドライン愛好家ではありません(少なくとも、Gitを学び始める前はそうではありませんでした)が、コマンドラインでGitを使用するのは本当に簡単です。何か不足していますか?
キラレッサ

80

Git対Mercurial

Mercurialは一般に、Gitよりも簡単で習得しやすいと考えられています。同様に、Gitはより柔軟で強力であるという認識がしばしばあります。これは、一部にはGitがより低レベルのコマンドを提供する傾向があるためですが、一部にはデフォルトのMercurial が高度な機能を非表示にする傾向があり、ユーザーが希望する高度な機能をアクティブにするために水銀設定ファイルを編集できるようにするためです。多くの場合、これはMercurialでは高度な機能を利用できないという認識につながります。

Gitの概念

Mercurialは常にインターフェースの側面に重点を置いてきたため、元々学習が容易になりました。Gitと比較して、Mercurialを便利な方法で操作するには、より浅い理解が必要です。長い目で見れば、このようなカプセル化は、Mercurialに実際よりも強力で機能性が低いという誤った外観を与えています。


73
そのため、Mercurialは高度な機能のみを非表示にし、GITはすべての機能を非表示にます... ;

4
Gitにもっと強力な機能があります。たとえば、gitのHEAD〜1に相当するものはありません。Mercurialには、ブランチにまたがるp(x)があります。Hgにはステージはありません。プッシュするときは、すべてのブランチをプッシュする必要があります。Mercurialは、histedit、shelf、rebaseなどのすべてのプラグインを使用した場合でも、柔軟性に欠けます。Gitのコマンドラインも優れており、ユーザーにヒントを提供しますが、mercurialは提供しません。私は職場でこのわずかに障害のあるDVCSを使用せざるを得ず、水銀が自分のやりたいことをする力に欠ける状況に陥りました。
Keyo

22
@Keyo:Mercurial ~にはrevsetsがあります。ステージング領域はありませんが、MQを使用してエミュレートできます。MQは非常に強力です。gitから知っていることにこだわるのではなく、このツールを使用する方法を学んでください。
イダンK

22
@Keyo:プッシュするときにMercurialですべてのブランチをプッシュする必要はありません。特定のブランチ(hg push --branch BRANCH)または特定のリビジョン(hg push --rev REV)までプッシュできます。hg help pushその他のオプションについてはご覧ください。
リージェント

1
参考までに、レコード拡張子を使用して、ステージング領域のかなりのサブセットを取得できます。OTOH、シェルフエクステンション(Baazarの "shelve"コマンドに基づいてモデル化され、 "git stash"に近い)は、ステージング領域を使用するほとんどの目的にはるかに役立つと思います。
ブランディッツィ

47

コンテキスト:Mercurial(仕事用)とGit(サイドプロジェクトおよびオープンソース用)の両方を毎日使用しています。私は主に(IDEではなく)両方でテキストベースのツールを使用し、Macを使用しています。

一般に、Mercurialの方が使いやすいと感じています。私が見つけたいくつかのことがMercurialを簡単にします。

  1. インデックスの欠如。 インデックスは、Gitの多くの機能を有効にする強力なツールですが、私が定期的に行う多くのことへのステップを追加する追加のレイヤーでもあります。Mercurialのワークフローは、svnのようなものに似ています。
  2. shaの代わりにリビジョン番号。 これは、Mercurialで毎日のコマンドを簡単に操作できるようにする小さなことです。コマンドの作成中にリベース、マージなどの際にいくつかのリビジョン番号を頭にプッシュする方が、短縮されたshaで同じことをするよりも簡単です。
  3. 枝。 コミットに名前を付けることによるブランチに対するGitのアプローチは強力であり、他のバージョン管理システムとは大幅に異なります。特定のことが非常に簡単になります。Mercurialのアプローチはsvnの考え方に少し似ていて、ブランチの履歴を視覚的に理解しやすくすることがわかります。これは単に好みかもしれません。

6
インデックスに言及するための+1。インデックスとその相互作用は Gitを水銀よりも学習しにくくするものだと思います。
ショーンマクミラン

18
hg同等のgit分岐が実際に呼び出されbookmarks。私の知る限り、hgブランチにはに相当するものがありませんgit
ハンクゲイ

6
私は同じ状況にあります。職場では水銀で、自宅ではgitです。Mercurialのブランチはかなり面倒です。プライベートブランチを用意して、好きなときにプッシュするのが好きです。Mercurialは、シェルフまたは追加のリポジトリを使用するように強制します。リビジョン番号はばかげているので、ハッシュを教えてください。gitのステージは素晴らしいです、私はこれが恋しいです。私は本当にgitの力を失っています。私はいくつかのプラグインでいくつかのことを行いましたが、分岐は本当に私を悩ませます。
Keyo

6
@Keyo-私の経験でgitは、分岐は分岐のサブセットですhg。ではhg、あなたの両方の名前と名前なし(位相幾何学)の支店を持つことができ、さらに同じように、名前の枝を管理できるgitブックマークを使用。ステージングエリアのポイントを見たことはありません。むしろ不要な変更を棚上げしてから、コミットする前にコードがテストをコンパイルして完了することを確認します。その後、シェルフを解除して続行できます。また、チャールズベイリーの「マッサージハンク」(p90 +)は私を怖がらせます* 8 '):accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
マークブース

7
@Keyo:Mercurialでは、プライベートブランチは「ブックマーク」と呼ばれます:ルートリビジョンに更新し、、処理をhg bookmark keyo-stuff行いhg commit、最終的にhg push -B keyo-stuff。リビジョン番号が気に入らない場合は、使用しないでください。Mercurialは、リビジョン番号を受け入れる場所であればどこでもハッシュを受け入れます。実際、Mercurialの機能が不足しているためにMercurialを攻撃しているというコメントは、無知で少し攻撃的であると感じています。あなたはGitユーザーのステレオタイプに対してあまり良いことをしていません!
トムアンダーソン

29

これは非常に主観的なものであり、人によって異なりますが、はい、VCSがまったく新しい人や「古い学校」のVCSから来た人には、Mercurialの方が簡単だと思います。

たとえば、ファイルを追加する、Hgにインデックスが存在しない、いくつかの最も「明白な」例として、古いリビジョンに戻ってそこから分岐する(更新およびコミットする)だけの簡単さ。現在、1つのシステムのほとんどの機能を別のシステムでエミュレートできますが、Gitである程度の知識が必要ですが、Mercurialではデフォルト(ユーザーに呼び出しを許可する場合)はかなり「ユーザーフレンドリー」です。これらのささいなこと-あちこちのスイッチ、1つのコマンドでの非自明な動作など...これらのことは重なり合い、最終的に、1つのシステムが他のシステムよりも使いやすいように見えます。

答えを完成させるだけです。私はgitを使用していますが、「初めて」の人にVCSを勧めるときは、ほとんど常にMercurialをお勧めします。私が覚えているのは、それが最初に手に入ったとき、非常に直感的だったと感じたことです。私の経験では、MercurialはGitよりも少ないwtf /分を生成します。


「wtf /分未満」の場合+1「これは非常に主観的」の場合-1。それはあまり主観的ではありません... UIの違いが依然として主観的であると人々が考えている理由はわかりません。Mercurialを取り、md5のコマンドをハッシュする場合、一部の人々がmd5ハッシュをオリジナルよりも直感的に感じるかもしれないという議論をしないでしょうか?(私はそうは思わない)。Gitについても同じことが言えます。Gitの経験がMercurialよりもかなり充実している場合、GitはMercurialよりも簡単です。
weberc2

17

私はそれはこれと同じくらい簡単だと思います:Mercurialは(特にSVNユーザーにとって)より馴染みのある構文を持ち、かなりよく文書化されています。Git構文に慣れると、他のGit構文と同じくらい簡単に使用できます。


7
いや。ワークフローのステップが多すぎるため、「異なる構文」と呼ぶことはできません。Gitを使用するには、操作している基礎となるモデルとgitインデックスのすべての状態を理解する必要があります。SQLとPascalは、同じことに対する2つの異なる構文であると言っても、同様に間違っています。Gitは、DVCS機能を備えたファイルシステムコンテンツバージョン管理システムです。Mercurialは、DVCSユーザーがすべて必要とするサブセットのみをGITが行うすべてのファイルシステムコンテンツのバージョン管理操作を行うわけではないDVCSです。
ウォーレンP

9

これに関して、認識は時間とともに変化する可能性があります。Mercurialは非常にうまく設計されており、Gitも同様です。Mercurialは習得しやすいように思われます(少なくとも私にとってはそうでした)。Gitで遭遇した困難、Mercurialでの類似点はありませんでした。私はPythonとRubyを学ぼうとしましたが、Pythonでさらに速く、速くなりました。だからといって、Pythonが常にどこでもRubyより優れているというわけではなく、私にとっても優れているというわけでもありません。それは私が学んだこと、そして行き詰まったことです。プログラマーはしばしば個人的な好みから聖戦を行います。他の人間もそうしています。

私はGitについてオープンな心を保とうとする水銀ユーザーであり、Mercurialほどには「私の新しいお気に入りにならない」ことを自由に認めています。Gitは本当に素晴らしいと思います。

GIT / mercurialの複雑さの反例:素晴らしいGITサポートがMacのXCodeに組み込まれています。GITよりもMercurialでのXCodeの使用は簡単ではありません。

GITでのこれまでの経験では、混乱して迷子になり、使用中にドキュメントを参照する必要がありました。私は多くのドキュメントが書かれたと信じていますが、それを「グロッキング」することを可能にしたものは何もありません。第二に、PythonでMercurialを簡単に変更および拡張できます。Pythonに精通しているので、誰でも実際にPythonをすばやく学ぶことができるので、それは私にとって利点のようです。私もCを知っており、CでPython拡張機能を作成しているので、いつか必要になったら、CでGit拡張機能を簡単に作成できると思います。

使いやすさは、簡単に定量化できるものではありません。それはそこにあり、私はそれが完全に主観的であるとは思わないが、我々は良い客観的な測定技術を持っていません。使いやすさの単位は何ですか?Milli-iPods?

私は100%プロ水銀であり、100%反gitであるほど党派ではありません。私は現在、Mercurial、Windows、およびLinuxに慣れており、さらにMacの作業を開始するときには、XCode + GITに固執することを期待しています。

更新2013: MercurialとGITを使用して、マージ戦略に関するこの質問など、Gitに必要な機能を見つけられるようになりました。Gitは、学ぶのが難しくても、驚くほど複雑で、時には気が遠くなるほど複雑です。


7

IMOが新しいユーザーをGitから遠ざける可能性が高いことはいくつかあります。

  1. Gitカルチャはコマンドライン中心です。両方のツールはコマンドラインに集中しすぎる傾向がありますが(何度か言ったように、コマンドラインの指示は強力で流かもしれませんが、良いマーケティング戦略ではありません)、これはGitの場合にはるかに当てはまります。MercurialにはTortoiseHgの事実上の標準GUIツールがありますが、これはMercurialホームページのWindowsユーザー向けのデフォルトのダウンロードオプションでもありますが、Gitには競合するGUIフロントエンド(TortoiseGit、Git Extensions、gitkなど)があります。 GitのWebサイトで、いずれにしても完全に目障りです。(赤いラベルの黒いテキスト?C'mon、TortoiseGit、あなたはそれよりもうまくやることができます!)また、GUIツールを使用する人々は適切なソフトウェア開発者ではないというGitコミュニティでのより広範な態度があります。

  2. Gitには、すぐに使用できるデフォルトがいくつかあり、上級ユーザーには完全に理にかなっていますが、新しいユーザーを脅かさない限り驚くかもしれません。たとえば、マージなどのタスクの自動化がより積極的です(たとえば、git pullは可能な場合は自動的にマージおよびコミットします)。完全に自動化されたマージの場合もありますが、ほとんどの経験のないユーザーはマージが怖いので、ソースコードを最大限に活用する前にツールに自信を持つ機会を与える必要があります。

  3. ドキュメントと固有の複雑さ:

    $ hg help log | wc -l
    64
    $ git help log | wc -l
    912
    

3
実際、64行のヘルプよりも912行のヘルプの方が好きです
。-ディザスター

10
実際、私は直感的でシームレスなUIを好み、そもそもヘルプを必要としません。
ジャミーケーキ

2
GUIとヘルプの両方が必要です。:)私にとって直感的に思えるのは、他の誰かの混乱です。
災害2011年

1
確かに、しかし助けが必要なとき、それは従うのが簡単であるべきです。
ジャミーケーキ

3
新しい類推を考えました。GitはC ++(ごめんLinus!)のようなもので、MercurialはPascalのようなものです。暗黙的で、Pascal(またはMercurial)で1つの方法でしか実行できないことは、C ++(およびGit)では19の異なる方法で明示的に実行できます。一部の人々は、より多くのボタンとレバーを備えたパワーツールを好むが、Gitはそれだ。
ウォーレンP

3

私が考えることができる一つのことは

git add .
git commit -am "message"

hg ci -Am "message"

git commit -aは、新しく作成されたファイルを追加しませんhg ci -A。これは、Gitで2つのコマンドを必要とする何かをMercurialの1つのコマンドで実行できることを意味します。繰り返しますが、「タイピングが少ない」とは、必ずしも「よりユーザーフレンドリー」という意味ではありません。


11
私のワークフローでは、新しいファイルを自動的に追加することは実際には望ましくないことがよくありますgit commit -a特定のコミットで追加されるものとされないものを簡単に制御できるため、単純に機能する方法を好むようになりました。(実際にはsvn ci、コミットに無関係な内容を追加しないように、個々のパス名を指定することは私にとって珍しいことではありません。)
greyfade

3
十分に公平ですhg ciが、-Aフラグなしではに相当すると思いますgit commit -a。私はgitをhgよりもずっと多く使用しているので、100%確信はありません。
Zhehao真央

確認しました、hg ci== git commit -a
Zhehao真央

ただし、hg commitで特定のファイルを指定すると、不要なファイルを取り込むことを回避できます。このコントロールを必要とするまれなケースでは、これはうまく機能します。
アレックスミラー

1
なぜ "git add。" そして「git commit -am」?すべてがすでにインデックスに追加されていませんか?
-jacobangel

3

その理由は。

Gitは、水銀よりもはるかに内臓を露出します。Mercurialを拾ってから数分以内に喜んで使用できますが、Gitを2か月間苦労して取り組むのはまだ難しいと思います)。私はコマンドラインからも、主にLinux上でも両方を使用しているので、これはコマンドラインインターフェイスに対する単なる嫌悪ではありません。

1つの簡単な例は、gitと比較してMercurialに必要なフラグとコマンドライン引数が比較的少ないことです。ステージング領域とgitのaddコマンドの動作により、必要以上に複雑さが増します。リセット、チェックアウト、復帰、およびそれらの複数の順列のトリオにより、非常に複雑になります。

Hginitについての上記のコメントにも同意します。水銀が間違いなく理解しやすくなりました。よく書かれており、非常に理解しやすい。git用に書かれたドキュメントはどれも近づいていません。私にとっては、Scott Chacone(Gitに関するドキュメント/書籍のほとんどを独力で書いた)によって書かれた内容のほとんどが特に混乱していることに気づきました。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.