Git / Mercurial / Bazaarの人気とおすすめ
この3つの分散バージョン管理システムに関するこのサイトの質問の数を見ると、Git
- より人気がある、または
- より難しい（より多くの質問を必要とする）、または
- より多くの機能があります（したがって、より多くの質問が必要です）。
または、おそらく3つの組み合わせです。 （このサイトでの人気は、一般的な人気に等しいとしましょう。）数値は次のとおりです。
3つの競合するが、ほぼ同等のオープンソース製品を選択することは、完全に満足できるものではありません。個人的にはGitを使用していますが、他の2つでも大丈夫です。しかし、あるシステムを他のシステムよりも推奨することになると、私は尋ねたいと思います。安全に推奨するシステムをまだ始められますか？
2009年半ばからのコメント：Subversionの最近の歴史的な人気は、質問の数に明確に反映されており、少なくともGitに向けてスケールがわずかに傾いていることを示していますマーキュリアルまたはバザールの上。
2010年半ばからのコメント：Mercurial番号のその相対的な増加を見てください。明らかに、2つのデータポイントだけでは傾向を示すのに十分ではありませんが、GitとSubversionの大部分は定着しており、Mercurialは大きく成長しており、Bazaarは比較的静かなままです。
簡単なコメント、2011年半ば：Gitを勝者と呼ぶことはできますか？ :)いいえ、質問の数は人気に相当しないという議論を受け入れます。ただし、数字は確かに強力です。
上記のプロットを再現するコード：
import datetime as dt
import matplotlib.pyplot as plt
dates = [
"01/06/2009",
"01/07/2010",
"01/07/2011",
"01/07/2012",
"01/07/2013",
"01/07/2014",
"01/07/2015",
"01/07/2016",
"01/06/2017",
"28/08/2018",
"27/05/2019"
]
x = [dt.datetime.strptime(d, "%d/%m/%Y").date() for d in dates]
git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362, 110970]
svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525, 25868]
Mercurial = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765, 7894]
Bazaar = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539, 544]
ax = plt.gca()
ax.grid()
plt.plot(x, git, label="[git]")
plt.plot(x, svn, label="[svn]")
plt.plot(x, Mercurial, label="[Mercurial]")
plt.plot(x, Bazaar, label="[Bazaar]")
plt.gcf().autofmt_xdate()
plt.ylabel("number of tags on stackoverflow")
plt.ylim(0)
plt.legend()
# plt.show()
plt.savefig("comparison.png", transparent=True, bbox_inches="tight")
import datetime as dt
import matplotlib.pyplot as plt
dates = [
"01/06/2009",
"01/07/2010",
"01/07/2011",
"01/07/2012",
"01/07/2013",
"01/07/2014",
"01/07/2015",
"01/07/2016",
"01/06/2017",
"28/08/2018",
"27/05/2019"
]
x = [dt.datetime.strptime(d, "%d/%m/%Y").date() for d in dates]
git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362, 110970]
svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525, 25868]
mrc = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765, 7894]
bzr = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539, 544]
n = len(dates)
intervals = [x[i+1] - x[i] for i in range(n-1)]
git_per_day = [(git[i+1] - git[i]) / intervals[i].days for i in range(n-1)]
svn_per_day = [(svn[i+1] - svn[i]) / intervals[i].days for i in range(n-1)]
mrc_per_day = [(mrc[i+1] - mrc[i]) / intervals[i].days for i in range(n-1)]
bzr_per_day = [(bzr[i+1] - bzr[i]) / intervals[i].days for i in range(n-1)]
ii = [0] + [val for val in range(1, n-1) for _ in (0, 1)] + [n-1]
jj = [val for val in range(n-1) for _ in (0, 1)]
ax = plt.gca()
ax.grid()
plt.plot([x[i] for i in ii], [git_per_day[j] for j in jj], label="[git]")
plt.plot([x[i] for i in ii], [svn_per_day[j] for j in jj], label="[svn]")
plt.plot([x[i] for i in ii], [mrc_per_day[j] for j in jj], label="[Mercurial]")
plt.plot([x[i] for i in ii], [bzr_per_day[j] for j in jj], label="[Bazaar]")
plt.gcf().autofmt_xdate()
plt.ylabel("average daily tags on stackoverflow")
plt.legend()
plt.ylim(0)
# plt.show()
plt.savefig("comparison-daily.png", transparent=True, bbox_inches="tight")
2011年11月の更新：
Gitは2009年に比べてはるかに成熟しています。
- スマートhttp がサポートされるようになりました。これは、クライアントhttpsプロトコルにプル/クローンおよびプッシュを提供し、認証がLDAPとインターフェースできることを意味します。 （企業内のユーザーにとって重要）
- 成熟した承認レイヤーが Gitolite で存在するようになりました。つまり、「機密」リポジトリを分離できます（これも大企業にとって重要です）。
- 2009年に既に存在していたWindowsサポートは引き続き強力であり、 TortoiseGit は非常に安定しています。
- Eclipseと同様にIDEとの統合が進行中です（現在、EclipseプロジェクトのほとんどはGitHub上にあります）
ただし、Gitを集中環境にインストールするのは簡単ではありません。
「 Distributed Version Control Systems and the Enterprise-a good mix？ 」を参照してください
一貫して見過ごされている1つの点は次のとおりです。
それらは本質的にdifferentです。
- SVNはREVISIONシステム（安価なコピーのみでブランチとタグを保存します！マージサポートはあまり効率的ではありません）、そして一元化されています。
- MercurialまたはBazaarは、FILE VCS（filesのバージョンを格納）、および配布されます。
Arne Babenhauserheide Mercurialの 履歴モデル トラックcontent-changes、ファイルシステムへのアクセスを最適化するためにストレージパスでファイルパスが再利用されます。 - Gitは、把握するのが非常に難しい、 [〜＃〜] content [〜＃〜]VCS （ファイル自体ではなく、contentのデルタを格納します。同じコンテンツを持つ2つのファイルは1回だけ格納されます）
つまり：
- 単純なマージワークフローがある場合、単一の開発場所でSVNを使用します
- 複数の開発場所がある場合、分散VCSはより適応されます。
- 複雑なマージワークフロー を使用している場合、最新のVCSは、長年にわたって適切な場所にマージ情報を保持するのに苦労するSVNよりも優れています。次に、ツールに依存します（Mercurialは、たとえば、より高度なWindowsサポートを備えています）
- 主にテキストファイルを使用し、バイナリファイルが大きすぎない場合は、その制限を知っていれば、Gitは優れています。
これらの3つの分散バージョン管理システムについて、このサイトの質問の数だけ見ると、Gitのようです
- の方が人気がある、または
- が難しい（より多くの質問が必要）、または
- には、より多くの機能があります（したがって、さらに質問が必要です）。
SCMについてpopularity-次のStackOverflowの質問を参照してください： 人気がありますか/無料のRCS/SCM/VCSシステムで利用可能な統計情報？ 。ここでは、SCMに依存しない特定の種類のプロジェクトに使用する無視ファイルのセットなどの質問がありますが、Git（および「git」タグを使用）が求められます。
Gitについてより難しい（したがって、SOについてより多くの質問がある）-確かにGitはより急な学習曲線。また、ステージングエリア（インデックス）、またはすべてのブランチが等しいなど、そのパワーを担う少数の（非常に）ユニークなコンセプトを使用しますが、最初は正しく取得するのが難しい場合があります（特に他のSCMから来た場合） 。また、Git UIは完全に一貫性がありません（ただし、改善されています）。これはその力に責任がありますが、最適でないユーザーインターフェイスにつながる可能性があります。
その他の機能を備えたGitについて-SO質問は、Gitの高度/一般的でない機能に関するものです。ただし、オープンソースプロジェクトは互いにアイデアを借用するか、同様の機能を独自に開発することに注意する必要があります：1つの例は、（私の知る限り）開発されたバグを導入したコミットの履歴を二分することでバグを見つけることですまずGitで、次にBazaarでプラグインとして実装され、Mercurialで最初の拡張機能と現在のコア機能です。別の方法は、Darcsの振る舞いに触発されて、コミットする変更の断片をインタラクティブに選択することです。さらにもう1つは、Gitのバンドルアイデアで、Mercurialの同様のコンセプトから借用しています。
さらに多くのSO質問のソースの可能性は、優れたドキュメントの欠如...最近では Git User's Manual （Gitと共に配布）および Git Community Book （Gitホームページにあります）で改善されています。それでも、Gitには Subversionを使用したバージョン管理 （svnbookとしても知られている）および- Mercurial：The Definitive Guide （別名hg-book）...そしてStackOverflowで質問する前にドキュメントを読まないことがあります。
3つの競合するが、ほぼ同等のオープンソース製品から選択することは完全に満足できるものではありません。個人的にはGitを使用していますが、他の2つでも大丈夫です。しかし、あるシステムを他のシステムよりも推奨することになると、私は尋ねたいと思います：私たちはまだ安全にシステムを推奨し始めることができますか？
さて、GitとMercurialは、Linuxカーネル開発者が使用するBitKeeperの無料ライセンスの代わりとして、ほぼ同時に独立して開発されました。 Subversionは集中型SCMとして問題外でしたが、マージトラッキングのサポートがコアにありませんでした。このため、Linuxカーネルの大部分が分散した開発モデルにはまったく適していません。 Bazaarはおそらく（少なくともその時は）遅すぎ、集中化された側に少しありました（推測）。
Gitは（私の意見では）より強力であり、Mercurialは（人の意見では）よりシンプルで、移植性が少し（Python）です。 Gitはスクリプト可能で、独立した再実装を可能にするデータモデルに基づいています（たとえば、JGit、Javaで記述されたgitを参照）。Mercurialは拡張機能を記述するためのPythonバインディングを持ち（revlog-revlog-ng）...しかし、それは私の推測です。それらはわずかに異なる隙間を埋めます。
それに、良いものと考えられる選択肢がないのですか？ KDEがあり、GNOMEとXFCE（および他のウィンドウマネージャーとデスクトップ環境）があります。 EmacsとVim（および他のプログラマーのエディター）があります。 rpmベース（Fedora Core、Mandriva、SuSEなど）およびdebベース（Debian、Ubuntu）およびtgzベース（Slackware）およびソースベース（Gentoo）のディストリビューションがあります。 KWord、AbiWord、OpenOffice.org ...があり、Git、Mercurial、Bazaarがあります。
Mercurialを使用および推奨します
- 分散開発をサポートしているため、Subversionではありません。複数のマシンで作業し、ローカルでコミットできます。少なくとも追加のリポジトリのような宙返りなしでは、Subversionでこれを行うことはできません。
- bazaarのWindowsサポートは...まあだからBazaarではなく。
- gitではなく、a）学習と使用が簡単で、b）Windowsサポートがはるかに優れているため
私の経験では、質問の数から判断すると、GitとMercurialに対する比較が著しく歪んでいます。理由は2つあります。
見て
hg update --help対git checkout -hおよびgit --help checkout。 Mercurialでは、hg help。Mercurial Wiki-ヘルプが必要な場合、あなたはおそらくそこにそれを見つけるでしょう、多くのヒントとコツを含みます： http://Mercurial-scm.org/wiki/TipsAndTricks
[注：Subversion 1.7のリリースでは、以下の回答の最初の段落は古くなっています。これは、Subversionがベースフォルダーに単一の「.svn」フォルダーを作成するようになったためです。
Subversionに対する3つのいずれかの利点は、プロジェクトのすべてのフォルダーに「.svn」フォルダーに相当するものが作成されないことです。通常、ベースフォルダーには1つ（ ".hg"、 "。bzr"、または ".git"）があります。集中リポジトリモデルを使用している場合でも、それだけでsvnでそれらの1つを使用する正当な理由になります。 （脇：実際、この機能のためだけにsvnリポジトリを使用する場合、 svk をsvnクライアントとして使用します（Linuxのみですが、svkはWindowsには適していません））。
もちろん、Subversionの利点の1つは、サブフォルダーの1つだけが必要な場合、プロジェクト全体をチェックアウトする必要がないことです。
Canonical（Ubuntu）は、ディストリビューションの ソフトウェアパッケージの使用量 を追跡するため、Stack Exchangeの問題数に依存して人気を測定する必要はありません。ただし、他の人が指摘したように、これはUbuntuユーザーとCanonical（Ubuntu）の使用を追跡し、bzr（サンプルバイアス）を推奨するだけです。それにもかかわらず...
2011 2011 2011
Package Aug 3 Sep 29 Dec 9 Change
------ ------ ------ ------ ------
git-core 3647 3402 3236 -11%
bzr 4975 5286 6070 +22%
Mercurial 3411 3387 3461 +1%
Git-coreパッケージの投票数の減少は、ubuntu人気テーブルから間違ったパッケージ名をgrepedしたような間違ったことをしたように思わせます。または、この「投票」カウントでさえ、ソフトウェアの実際の使用ではなく、インストールに関連しています。
これがトレンドの履歴データです。この表では、Ubuntuの<install>統計ではなく<vote>統計を使用しましたが、2011年からBazaarとMercurialの成長が急増しています。それにもかかわらず、bzrはgit 2011年ですが、2011年の最近の統計では、インストールされたインスタンスの合計（Ubuntu上）でgitをパスしたことが示されています。
June Aug Dec Growth Oct Growth
2010 2011 2011 2013
---- ----- ---- ---- ------ ---- ------
git 94k 159k 171k 80% 165k -3.5%
bzr 52k 121k 135k 160% 170k 26.0%
hg 36k 68k 75k 110% 95k 26.7%
Discalaimer：Ubuntuでgitのみを使用するチームで作業する2012年までbzrを使用していました。 Bzrは他のすべてのVCSでNiceを再生するため、一貫性のある直感的なbzrコマンドライン構文を使用できます。 gitへの切り替えは、技術的な理由ではなく社会的な理由によるものです。
GitHub でGitを使用したソーシャルコーディングの起源以来、Gitは多くのフォロワーを惹きつけたようです。
Gitが非常に多くのユーザーを持っている理由は、Linuxカーネルがそれを使用しているためです。したがって、Linux開発を行う場合は、gitを使用します。
非常に多くの人々がgitに関与しているので、単にユーザーベースが大きいため、gitを使用することをお勧めします。実際、上に示した数字はこれを明確に示しています。
難易度については、すべてのバージョン管理、特に分散型の管理が困難です。 SVNとCVSは、一見したところ（少なくとも私にとっては）簡単ではありませんでした。これは、バージョン管理システムに慣れるのに必要な学習曲線の一部にすぎません。
編集：あなたはSubversionリファレンスを追加したので、私はそれに対処すると思いました。ほとんどの人がsvnを使用すると思うのは、それがあらゆる種類のGUIインターフェースを持っているからです。一般に、一部の開発者を含む人々はコマンドラインを使用することを嫌います。 gitは通常、Windowsでもうまく機能しません（少なくともシームレスに機能しません）。多くの人がWindowsを使用しているため、これにより潜在的なユーザーの数が減少します。
さらに、svnは分散システムではなく中央リポジトリを使用するため、SVNの概念は少し理解しやすいと思います。 「ここにコードの山があります。ここにコードを追加してください。」「コードはここにあります。私のものは彼とは異なるかもしれませんが、必要に応じて何かを追加できます。」
私の意見では、svnの方がはるかに優れたドキュメントシステムがセットアップされています。 gitのドキュメントは（プログラマーの知能ではなく、プログラムの）少し高いレベルの知識を対象としているため、システムを使用した後は理にかなっていますが、最初に起動すると、まるでゴブベルクのように見えます。
全般的に、svnは一般的な操作の概念が理解しやすく、ツールが使いやすく、Windowsで素晴らしいサポートがあるため、常に普及していると思います。
最後の2セントで終了させてください。Gitは私が使用した他のどのシステムよりも強力だと思うので、Gitの方がずっと好きだと言います。プログラムをよりよく理解し始めたら、学習曲線を登ることは間違いなく成果があります。
この件に関するアンケートへの次のリンクを確認してください。
通常は投稿しませんが..
私はgit、bzrなどを試してみましたが、忘れてしまいましたが、bzrには非常に弱点があることがわかりました。大きなファイルの場合、ファイル全体をメモリにロードすることを要求します。これにより、大きなバイナリの問題が発生します。
その点で、Gitははるかに優れていました。難易度について。私はgit bashのウィンドウでgitを使用します。素晴らしい作品で、1週間足らずで学習しました（実際の作業と他のVCSでの実験を含みます）
興味深い ブログ投稿 Eric Sinkからそれらすべてについて。