少しコンテキスト:私は大学3年生です。学生は4人のチームに分けられます。ほとんどすべての人がWindowsで作業します(Linuxを使用している私のような一部を除く)。学校のカリキュラムの一環として、まもなく実際のクライアント向けのプロジェクトに取り掛かりますが、私と他のチームは、コードをお互いに共有するのに最適な方法を考えています。
私は3年間パートタイムで働いており、さまざまなプロジェクトでgitとMercurialの両方を使用した経験が豊富なので、どちらのシステムを使用しても問題はありません。しかし、私のチームメイトは、これまでにバージョン管理システムを使用したことがありません。 SVNを使用してみたが、大きな問題があり、他のことを試してみたいと思う別のチームもいるので、彼らは私の意見を求めました。
私の考え:Mercurial + TortoiseHgの方がWindowsでの統合が優れていると聞いたことがありますが、匿名の頭の概念を説明しても混乱するのではないかと思っています。一方、gitブランチは初心者には理解しやすい(各プログラマーの作業を明確に分離する)が、Windowsではうまく機能しないことがわかります。
水銀、間違いなく
これはもちろん、主観的なものであり、人によって異なりますが、一般的には、Mercurialの方が、特にVCSを初めて使用する人や、古い世代のVCSを使用する人にとっては、簡単に理解できます。
手元のポイント:
MercurialはWindowsを念頭に置いて開発されました; Gitが移植されました。誰かが私に伝えようとしたことに関わらず、GitはWindowsでまだ二流の市民です。過去数年間で状況は確実に改善されましたが、* nixボックスでのようにWindowsで何かが機能する、または機能しない理由についてはまだ多くの問題があります。 TortoiseHgは非常にうまく機能し、Visual Studioの実装は、ワークフローを中断することなく、さらに使いやすくなっています。
誰かが「Gitはあなたよりも強力だ...」という議論を始めると、彼はそれをすべて言っていることになります。95%のユーザーにとってMercurialはより直感的。インデックスの欠如から始まり、より直感的なオプション(オプションスイッチは一貫性があります)、SHA1ハッシュの代わりにコミットのローカル番号(SHA1ハッシュはユーザーフレンドリーだと誰が思ったのでしょうか?)
Mercurialのブランチは、Gitのブランチと同じくらい強力です。 いくつかの相違点を説明した投稿 以前のリビジョンに戻るのは、「古いリビジョンを更新する」のと同じくらい簡単です。そこから始まります。新しいコミットを行うだけです。名前付きブランチは、使用したい場合にも使用できます。
さて、これらすべてが詳細であること、そしてそれらを学習できること、そしてすべてのものであることを知っていますが、問題は...これらのことは追加されます。そして結局のところ、一方はもう一方よりも単純で直感的に見えます。また、バージョン管理システムは、学習に時間を費やすものであってはなりません。プログラミングを学び、次にプログラミングするためにそこにいます。 VCSはツールです。
注意してください。私はGitとMercurialを毎日使用しています。どちらを使用しても問題はありません。しかし、誰かが私に推薦を求めたとき、私は常にMercurialを推薦します。それを覚えている、それが最初に私の手に渡ったとき、それは非常に直感的に感じました。 私の経験では、MercurialはGitよりもWTF /分が少ないだけです
TortoiseHg UIは、Windowsで素晴らしい体験をすることがわかりました。過去にGitを試すときに、代わりにコマンドラインに行ってしまいました。平均的なユーザーにとって、優れたUIはコマンドラインよりもはるかに親しみやすいものです。したがって、Mercurialを使用することをお勧めします。 (ワークベンチウィンドウには、Niceブランチグラフも含まれています。基本的な分岐の問題はすべて解消されるはずです。)
UIの観点から物事を理解すると、コマンドラインに移動してスクリプトを作成したり、手動操作を行ったりする可能性がありますが、そうする必要はありません。
3番目のオプションに興味がある場合は、 Fossil をお勧めします。一時的なWebサーバーをスローしてコードを共有する機能は、小さなプロジェクトでうまく機能することがわかりました。 Fossilは単なる実行可能ファイルなので、ソースとソースをサムドライブに入れて、あらゆる大学のコンピュータから使用できます。
使用する Fossil ui
どこにいても、他の学生にあなたと同期させるために、一時Webサーバーを起動します。また、チケットシステム、wiki、ブランチの変更やコミットのタグ付けのための使いやすいWebインターフェイスも提供します。
クイックスタートガイド や book を必ず読んでください。最後に、Web UIよりも使いやすいユーザーインターフェイスを提供する winFossil というプロジェクトがあります。
チームがバージョン管理に不慣れで、多くがWindowsを使用していることを考えると、GitよりもMercurialをお勧めします。
GitとMercurialで使用されるバージョン管理の概念モデルは非常に似ているため、1つを習得すると、もう1つを選択するのが簡単になります(同様の理由で、リポジトリを一方から他方に変換するのは非常に簡単です)。 。これは、後で気が変わっても大したことではないということです。
私の意見では、Mercurialは新しいユーザーが学ぶのが簡単です。それは単純なものを簡単にし、危険なものを難しくします。 Gitは危険な操作を簡単にします(実行するのは簡単ですが、必ずしも正しく実行するのは簡単ではありません!)。
WinodowsのTortoiseHgインターフェースも非常に優れており、Mercurialの使用を支持するもう1つの論拠です。
私の個人的な好みはgitです。
ただし、一部のユーザーはWindowsを使用していて、すばらしい hginit チュートリアルが存在するため、Mercurialを教えることをお勧めします。
多くの人々が示唆しているように、 Mercurial を介して TortoiseHg を使用すると、エントリに対するバリアが非常に低くなります。
Windowsの場合、これは2つのインストーラーではなく単一のインストーラー(そして、彼らが知りたくないかもしれないもの全体)であり、THgユーザーインターフェイスは TortoiseGit + Msysgit 。
匿名の頭で混乱すると思われる場合は、その使用を奨励しないでください。ほとんどのhg
の本は、バランスのとれたアプローチをとり、トポロジーと名前付きブランチの両方を教え、読者にそれらの使用に最も適切なものを決定させます。
git
で私が本当に見落としているのは、hg
の名前付きブランチ、それが1つのオプションです。 git
ブランチは作業中は問題ありませんが、その作業を別のブランチにマージすると、それらの変更のコンテキストの多くが失われます。
hg
では、Jira#1234
というブランチを作成し、それに関連するすべてのリビジョンを常に見つけることができますfix 。 git
では、ブランチがマージされ、refが削除されたら、リビジョンツリーのトポロジから、修正の一部であったリビジョンを推測する必要があります。参照を削除しなくても、そのブランチの最後のコミットのみがわかります。その祖先のどれがコミットのチェーンの一部であったかはわかりません。
または、名前付きブランチを使用したくないが、匿名ブランチでgit
スタイルのワークフローが必要な場合は、代わりに bookmarks を使用できます。
これは両方の長所かもしれません-彼らはgit
ワークフローを学ぶことができますが、より単純なhg
コマンドを使用することができます。
個人的には、学生はgit
の匿名の頭よりもhg
のインデックス/キャッシュ/ステージング領域で混乱する可能性がはるかに高いと思います。私はhg
が常に使用したい/使用する必要があると仮定する方法よりも、コマンドラインでこの高度な機能をオプションにするgit
を好みます。
また、ステージング領域は、テストもコンパイルもされていないコミットを奨励すると思います。私が働いたことのある場所の多くには、コンパイルしない場合はコミットしないルールがあるため、むしろ shelve / stash 変更したくない現在、単体テストを再実行し、コンパイル済みのバージョンをコミットします。
後で hg bisect または git bisect を使用してバグを追跡する場合、コンパイルしたものだけでなく、すべてのリビジョンをテストできることに感謝します。