Git、Mercurial、Bazaar の相対的な長所と短所は何ですか?[閉まっている]
https://stackoverflow.com/questions/77485
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
ここの人々は、Git、Mercurial、Bazaar の相対的な長所と短所を何だと考えていますか?
それぞれを相互に考慮したり、SVN や Perforce などのバージョン管理システムと比較したりする場合、どのような問題を考慮する必要がありますか?
SVN からこれらの分散バージョン管理システムのいずれかへの移行を計画する場合、どのような要素を考慮しますか?
解決
Git は非常に高速で、拡張性に優れ、その概念が非常に透明です。この欠点は、学習曲線が比較的急であることです。Win32 ポートは利用可能ですが、完全に一流ではありません。Git はハッシュをバージョン番号としてユーザーに公開します。これにより、(単一のハッシュが常にまったく同じコンテンツを参照するという点で) 保証が提供されます。攻撃者は検出されずに履歴を変更することはできません）が、ユーザーにとっては煩わしい場合があります。Git には、ファイルの内容がファイル間を移動する場合でもファイルの内容を追跡するという独自の概念があり、ファイルを第 1 レベルのオブジェクトとして表示しますが、ディレクトリは追跡しません。git に関するもう 1 つの問題は、多くの操作 (たとえば、 リベース) これにより、履歴の変更が容易になります (ある意味、ハッシュによって参照されるコンテンツは決して変更されませんが、そのハッシュへの参照は失われる可能性があります)。純粋主義者の中には（私も含めて）それをあまり好まない人もいます。
Bazaar は適度に高速で (履歴が浅いツリーの場合は非常に高速ですが、現時点では履歴の長さに応じて拡張性が低くなります)、従来の SCM (CVS、SVN など) のコマンドライン インターフェイスに慣れている人にとっては習得が簡単です。Win32 は、その開発チームによって第一級のターゲットとみなされています。さまざまなコンポーネントに接続可能なアーキテクチャがあり、ストレージ形式が頻繁に置き換えられます。これにより、新機能 (さまざまな概念に基づくリビジョン管理システムとの統合サポートの強化など) を導入し、パフォーマンスを向上させることができます。Bazaar チームは、ディレクトリの追跡と名前変更のサポートが第一級の機能であると考えています。グローバルに一意なリビジョン ID 識別子はすべてのリビジョンで利用できますが、リビジョンを識別するためにコンテンツ ハッシュの代わりにツリーローカル revno (標準リビジョン番号、svn またはその他の従来の SCM で使用されるものに似ています) が使用されます。Bazaar は、履歴がローカル システムにコピーされるのではなくリモート サーバーに保存され、必要に応じてネットワーク経由で自動的に参照される「軽量チェックアウト」をサポートしています。現時点では、これは DSCM の中で唯一のものです。
どちらも、何らかの形式の SVN 統合を利用できます。ただし、bzr-svn は git-svn よりもかなり機能が高く、これは主にその目的で導入されたバックエンド形式のリビジョンによるものです。 [2014 年時点の更新:サードパーティの商用製品である SubGit は、SVN と Git 間の双方向インターフェイスを提供します。これは、bzr-svn に匹敵する忠実度であり、より洗練されています。私 強く 予算とライセンスの制約が許せば、git-svn よりも git-svn を使用することをお勧めします。
私は Mercurial をあまり使用したことがないので、詳しくコメントすることはできません。ただし、Git と同様に、リビジョンに対するコンテンツ ハッシュ アドレス指定があることに注意してください。また、Git と同様に、ディレクトリを第一級のオブジェクトとして扱いません (空のディレクトリを保存できません)。ただし、Git を除く他の DSCM よりも高速で、競合他社よりもはるかに優れた IDE 統合 (特に Eclipse の場合) を備えています。Mercurial のパフォーマンス特性 (Git にわずかに劣る程度) と優れたクロスプラットフォームおよび IDE サポートを考慮すると、win32 中心のメンバーまたは IDE に依存するメンバーが多数いるチームにとって、Mercurial は魅力的なものになる可能性があります。
SVN から移行する場合の 1 つの懸念は、SVN の GUI フロントエンドと IDE 統合がどの分散 SCM よりも成熟していることです。また、現在 SVN によるプリコミット スクリプトの自動化を多用している場合 (つまり、コミットを続行するには単体テストに合格する必要があります)、おそらく次のようなツールを使用することになるでしょう。 PQM 共有ブランチへのマージ リクエストを自動化します。
SVK は、Subversion をバッキング ストアとして使用する DSCM であり、SVN 中心のツールと非常によく統合されています。ただし、他の主要な DSCM (Darcs であっても) よりもパフォーマンスとスケーラビリティの特性が大幅に劣るため、履歴の長さまたはファイル数のいずれかが大きくなりやすいプロジェクトでは使用しないでください。
[著者について：仕事には Git と Perforce を使用し、個人プロジェクトや埋め込みライブラリとして Bazaar を使用しています。私の雇用主の組織の他の部門では Mercurial が頻繁に使用されています。以前、私は SVN を中心に大量の自動化を構築しました。それ以前には、GNU Arch、BitKeeper、CVS などの経験があります。最初は Git に非常に不快感を覚えました -- ユーザーが選択したワークフローに準拠して構築されたツールキットではなく、コンセプトを重視した環境であるという点で GNU Arch のように感じました -- しかし、それ以来、私は非常に快適に感じるようになりました。それ]。
他のヒント
Ogre 3D プロジェクトの Steve Streeting は、このトピックに関するブログ エントリを公開したところです (2009 年 9 月 28 日)。 Git、Mercurial、Bazaar の比較.
結局、彼は 3 つすべての長所と短所を見つけ、明確な勝者はいませんでした。プラスの面として、彼はどれを選択するかを決めるのに役立つ素晴らしい表を提供します。
短い読み物なので、強くお勧めします。
ここの人々は、Git、Mercurial、Bazaar の相対的な長所と短所を何だと考えていますか?
私の意見では ギット 強みは、そのクリーンな基本デザインと非常に豊富な機能セットです。また、マルチブランチ リポジトリとブランチの負荷が高いワークフローの管理に対する最良のサポートも備えています。非常に高速で、リポジトリのサイズも小さいです。
便利な機能がいくつかありますが、慣れるまでに少し努力が必要です。それらには以下が含まれます 見える 作業領域とリポジトリ データベース間の中間ステージング ARA (インデックス)。これにより、より複雑な場合のマージ解決の向上、増分コミット、ダーティ ツリーによるコミットが可能になります。 検出する ある種のファイル ID を使用してそれらを追跡するのではなく、類似性ヒューリスティックを使用して名前変更とコピーを実行します。これはうまく機能し、大規模な名前変更だけでなく、ファイル間のコードの移動を追跡できる非難 (注釈) が可能になります。
欠点の 1 つは、MS Windows のサポートが遅れており、完全ではないことです。もう 1 つの認識されている欠点は、たとえば Mercurial ほど文書化されておらず、競合製品よりもユーザーフレンドリーではないことですが、状況は変わります。
私の意見では マーキュリアル 強みは、優れたパフォーマンスと小さいリポジトリ サイズ、優れた MS Windows サポートにあります。
私の意見では、主な欠点は、ローカル ブランチ (単一リポジトリ内の複数のブランチ) が依然として二級市民であり、奇妙かつ複雑な方法でタグを実装しているという事実です。また、ファイル名の変更を処理する方法も最適ではありませんでした (ただし、これは変更されている可能性があります)。Mercurial は、タコのマージ (2 つ以上の親を持つもの) をサポートしていません。
私が聞いたり読んだりしたことによると、主な内容は バザール 利点は、ファイルとディレクトリの両方の名前変更を追跡する、集中ワークフローのサポートが容易なことです (これは欠点でもありますが、集中概念が表示されるべきではない場所に表示されるため)。
その主な欠点は、長い非線形履歴を持つ大規模なリポジトリのパフォーマンスとリポジトリ サイズ (少なくとも大きすぎないリポジトリではパフォーマンスが向上しました)、デフォルトのパラダイムがリポジトリごとに 1 つの牧場であるという事実です (ただし、データを共有するように設定することはできます)。 、そして集中化された概念（しかし、私が聞いたところによると、それも変化します）。
Git は C、シェル スクリプト、Perl で書かれており、スクリプト化可能です。Mercurial は C (パフォーマンス重視のコア) と Python で書かれており、拡張機能用の API を提供します。Bazaar は Python で書かれており、拡張機能用の API を提供します。
それぞれを相互に考慮したり、SVN や Perforce などのバージョン管理システムと比較したりする場合、どのような問題を考慮する必要がありますか?
Subversion (SVN)、Perforce、ClearCase などのバージョン管理システムは、 集中化された バージョン管理システム。Git、Mercurial、Bazaar (および Darcs、Monotone、BitKeeper) は次のとおりです。 配布された バージョン管理システム。分散バージョン管理システムにより、より広範囲のワークフローが可能になります。「準備ができたら公開」を使用することができます。ブランチとマージ、およびブランチの多いワークフローのサポートが強化されています。簡単な方法で貢献を得るために、コミット アクセス権を持つ人を信頼する必要はありません。
SVN からこれらの分散バージョン管理システムのいずれかへの移行を計画する場合、どのような要素を考慮しますか?
考慮すべき要素の 1 つは、SVN との連携のサポートです。Git には git-svn があり、Bazaar には bzr-svn があり、Mercurial には hgsubversion 拡張機能があります。
免責事項: 私は Git ユーザーであり、少量の貢献者でもあり、Git メーリング リストを監視しています (そして参加しています)。私が Mercurial と Bazaar について知っているのは、そのドキュメント、IRC やメーリング リストでのさまざまな議論、さまざまなバージョン管理システムを比較したブログ投稿や記事 (そのうちのいくつかは、 Gitの比較 Git Wiki のページ)。
InfoQ は 素敵な比較.
Mercurial と Bazaar は、表面的には非常によく似ています。どちらも、オフライン コミットや複数のブランチのマージなど、基本的な分散バージョン管理を提供します。どちらも Python で書かれており、どちらも git よりも低速です。コードを深く掘り下げてみると多くの違いがありますが、日常的なタスクでは事実上同じですが、Mercurial の方がもう少し勢いがあるように見えます。
Git は初心者向けではありません。これは Mercurial や Bazaar よりもはるかに高速で、Linux カーネルを管理するために作成されました。これは 3 つの中で最も速く、またかなりの差を付けて 3 つの中で最も強力です。Git のログおよびコミット操作ツールは比類のないものです。ただし、これは使用するのが最も複雑で最も危険でもあります。特に git の内部動作を理解していない場合、コミットを失ったり、リポジトリを破壊したりするのは非常に簡単です。
Python 開発者が最近行った比較を見てみましょう。 http://wiki.python.org/moin/DvcsComparison. 。彼らは 3 つの重要な理由に基づいて Mercurial を選択しました。
Mercurial を選択したのは、次の 3 つの重要な理由からです。
- 小規模な調査によると、Python開発者は、BazaarやGitよりもMercurialの使用に関心があります。
- Mercurial は Python で書かれており、これは「自分のドッグフードを食べる」という Python 開発者の傾向と一致しています。
- Mercurial は bzr よりも大幅に高速です (git よりも遅いですが、その差ははるかに小さいです)。
- SVN ユーザーにとって、Mercurial は Bazaar よりも習得が簡単です。
私はしばらくの間、非常に気に入っていた Bazaar を使用していましたが、それは小規模なプロジェクトのみであり、それでもかなり遅かったです。とても簡単に習得できますが、すぐに習得できるわけではありません。ただし、非常に X プラットフォームです。
私は現在 Git を使用していますが、バージョン 1.6 では使用するコマンドの点で他の VCS とより似たものになったため、非常に気に入っています。
DVCS を使用した私の経験からの主な違いは次のとおりだと思います。
- Git には最も活気のあるコミュニティがあり、Git に関する記事がよく見られます。
- GitHub 本当にロックです。Launchpad.net も問題ありませんが、Github のような楽しみはありません
- Git 用のワークフロー ツールの数は膨大です。あらゆるところに統合されています。Bzr 用のものもいくつかありますが、それほど多くはなく、またそれほどよく維持されていません。
要約すると、DVCS に慣れ始めた頃は Bzr が素晴らしかったですが、今では Git と Github にとても満足しています。
これはコンテキストに大きく依存する大きな質問なので、これらの小さなテキスト ボックスの 1 つに入力するにはかなりの時間がかかります。また、これら 3 つは、ほとんどのプログラマーが行う通常の作業に使用する場合にはほぼ同じように見えるため、違いを理解するだけでもかなり難解な知識が必要になります。
これらのツールの分析をより具体的な質問に至るまで細分化できれば、おそらくより適切な答えが得られるでしょう。
私見ですが、Bazaar は git よりも学びやすいです。Git は github.com で優れたサポートを提供しています。
両方使ってみてどちらが自分に合っているかを決めると良いと思います。
ここの人々は、Git、Mercurial、Bazaar の相対的な長所と短所を何だと考えていますか?
これは非常に未解決の質問であり、炎上に近い質問です。
Git が最も高速ですが、3 つとも十分に高速です。Bazaar は最も柔軟性が高く (SVN リポジトリに対する透過的な読み取り/書き込みサポートを備えています)、ユーザー エクスペリエンスを重視しています。Mercurial はその中間です。
3 つのシステムにはすべてファンがたくさんいます。私は個人的にバザールのファンです。
それぞれを相互に考慮したり、SVN や Perforce などのバージョン管理システムと比較したりする場合、どのような問題を考慮する必要がありますか?
前者は分散システムです。後者は集中型システムです。さらに、Perforce は独自のものですが、他のものはすべて無料です スピーチのように.
集中型か分散型かは、そのカテゴリ内であなたが言及したどのシステムよりもはるかに重要な選択です。
SVN からこれらの分散バージョン管理システムのいずれかへの移行を計画する場合、どのような要素を考慮しますか?
まず、TortoiseSVN に代わる適切な代替手段が存在しないことです。Bazaarは独自に取り組んでいますが、 亀の亜種, しかし、2008 年 9 月の時点ではまだありません。
次に、分散型システムの使用が彼らの仕事にどのような影響を与えるかについて主要な人材をトレーニングします。
最後に、問題トラッカー、夜間ビルド システム、自動テスト システムなど、システムの残りの部分との統合です。
あなたの主な問題は、これらが 分散型 SCM は、ユーザーの考え方を少し変える必要があります。このアイデアに慣れると、技術的な詳細と使用パターンが定着しますが、特に企業環境では、最初のハードルを過小評価しないでください。すべての問題は人間の問題であることを忘れないでください。
ddaa.myopenid.com がついでに言及しましたが、もう一度言及する価値があると思います。Bazaar はリモート SVN リポジトリの読み取りと書き込みができます。つまり、チームの残りのメンバーが Subversion を使用している間に、ローカルで Bazaar を概念実証として使用できるということです。
編集：現在、ほぼすべてのツールが備えています いくつかの SVN と対話する方法ですが、私は今、次のような個人的な経験をしています。 git svn 作品 非常に 良い。私は何ヶ月もそれを使用していますが、問題は最小限です。
git に Linus Torvalds による優れたビデオがあります。彼は Git の作成者なので、これが彼が宣伝していることですが、ビデオの中で分散型 SCM とは何か、そして分散型 SCM が集中型 SCM より優れている理由を説明しています。git (mercurial は問題ないと考えられています) と cvs/svn/perforce の比較がかなり行われています。分散型 SCM への移行に関する聴衆からの質問もあります。
この教材は啓発的であることがわかり、分散型 SCM に興味を持ちました。しかし、ライナスの努力にもかかわらず、私の選択は気まぐれでした。理由は bitbucket.org です。私は、github よりも bitbucket.org の方が優れている (より寛大である) と感じました。
ここで警告の言葉を述べておく必要があります。ライナスはかなり攻撃的なスタイルを持っていて、面白くしたいと思っていると思いますが、私は笑えませんでした。それとは別に、このビデオは、分散 SCM を初めて使用する場合や SVN からの移行を検討している場合に最適です。
分散バージョン管理システム (DVCS) は、集中型 VCS とは異なる問題を解決します。それらを比較することは、ハンマーとドライバーを比較するようなものです。
集中型 VCS システムは、祝福された、したがって善である唯一の真の源が存在するという意図で設計されています。すべての開発者はそのソースから作業 (チェックアウト) し、変更を追加 (コミット) し、同様に Blessed になります。CVS、Subversion、ClearCase、Perforce、VisualSourceSafe と他のすべての CVCS の唯一の本当の違いは、各製品が提供するワークフロー、パフォーマンス、および統合です。
分散型 VCS システムは、あるリポジトリが他のリポジトリと同様に優れていることを目的として設計されており、あるリポジトリから別のリポジトリへのマージは単なる通信の形式の 1 つです。どのリポジトリを信頼すべきかに関する意味論的な値は、ソフトウェア自体ではなくプロセスによって外部から強制されます。
どちらのタイプを使用するかは組織によって異なります。プロジェクトまたは組織が集中管理を必要とする場合、DVCS は最適ではありません。開発者が中央リポジトリへの安全なブロードバンド接続なしで国中または世界中で作業することが予想される場合、おそらく DVCS が救いとなります。両方が必要な場合は、fsck を実行します。
