会社のバージョン管理システムを選択したい。これまでのところ、Git、Subversion、Mercurialがあることを知っています。
最近、Gitが最もよく使用されていることがわかりました。そのため、まだSubversionを使用する特別な理由があるのでしょうか、それともGitに直接アクセスする必要があるのでしょうか。
会社のバージョン管理システムを選択したい。これまでのところ、Git、Subversion、Mercurialがあることを知っています。
最近、Gitが最もよく使用されていることがわかりました。そのため、まだSubversionを使用する特別な理由があるのでしょうか、それともGitに直接アクセスする必要があるのでしょうか。
回答:
SVNはまったく死んでいません。まだ非常に広く使用されており、すぐにどこにも行きません。SVNは、特に分散バージョン管理が必要な分散プロジェクトを実際に実行していない場合、分散バージョン管理よりもはるかに簡単に使用できます。
中央リポジトリが1つしかない場合(これまでのところソース管理なしで十分に小さい場合に必要なすべて)、SVNを使用して対話する方がはるかに簡単です。たとえば、SVNを使用すると、1回の操作でリポジトリから変更をプルしたり、ローカルの変更をコミットしたりできますが、HGとGitでは同等の作業を行うために2つまたは3つの手順が必要です。
また、最近の改訂により、SVNは多くのパフォーマンスの問題を修正し、人々がHGとGitを好むようになりました。数年前よりも大幅に高速になりました。この時点では、実際に分散バージョン管理の高度な機能が必要でない限り、プロジェクトのHGまたはGitを検討する正当な理由はありません。
クライアントツールについてはまだ言及されていません。確かにコマンドラインスクリプトを使用してすべてを実行できますが、GUIを統合すると生産性が大幅に向上します。
私たちは主にVisual Studioと連携しています。IDEへの統合は、現在のGitよりもSVNの方が間違いなく優れています。これは将来変更される可能性がありますが、バージョン管理機能と同じくらいあなたの決定にこれを考慮に入れます。
他のすべてと同じように、バージョン管理システムはそれ自体が目的ではなく、目的地に到達するためのツールにすぎません。状況に応じて、最速でそこに到達するものを選択してください。
私はGitファンです。最近、Gitの欠点の1つは、svnのリリース番号とは反対にハッシュ付きのバージョンを識別することであることを認めなければなりませんでした。リリース番号は、電話などで簡単に伝えることができます。
そして、それが私が想像できる唯一のプロです。その機能に本当に依存したい場合は、分散型および/または集中型のVCS Bazaarで使用できます。Gitには、目的に役立つタグがあります。
とにかく、素早いブランチ切り替えとスタッシングなしで開発することは想像できませんでした。これら2つの機能だけでSVNに勝るものはありませんが、同じ目標を達成するためには、ツリー全体を別々のディレクトリに作成およびチェックアウトする必要があるという同じタスクを覚えています。
いわゆる「分散バージョン管理の高度な機能」には時間が付属しているので、最初からそれらを学ぶ必要はありません。それらを怖がらないでください。邪魔をするのではなく、あなたを助けるためにここにいます。また、DVCSの中央リポジトリを設定するのに問題はありません。
SVNを使用すると、リポジトリの一部をフォルダレベルまで簡単にチェックアウトできますが、gitでは、すべての履歴を含むリポジトリ全体を取得できます。
状況に応じて、これはSVNにいくつかの利点があります。
(これには、フォルダツリー全体に隠された ".svn"ガベージなどの大きな欠点もあります)。
「6時間で実行できるタスクがある場合、ツールの作成に6時間かかる場合でも、20分でそれを実行するツールを作成する方が良いでしょうか?」
分散バージョン管理は、取り組むべき別の獣です。開発者ごとに十分な学習が必要です。各開発者の学習プロセスに対応するバッファがある場合は、適切な分散バージョン管理システムに移行する必要があります。学習段階が終わると、分散バージョン管理は集中バージョン管理よりもはるかに優れています。
分散バージョン管理は偶然のようです。非常に長い間滞在するためにここにあります。それより早く適応する方が良いです。SVNが新しく、人々がCVSに慣れていて、SVNを使用しないことについて多くの議論が行われたとき、同じ議論を覚えていますが、最終的にSVNは最も人気のあるバージョン管理システムになりました。
会社が既存のバージョン管理システムに多くのソースコードを確立している場合、新しいシステムへの移行は大きな作業ですが、会社が小規模または新興企業の場合、新しいバージョン管理への移行は非常に簡単です。しかし、(新しいセットアップで)古いバージョン管理に固執すると、将来どこかでバージョン管理の移行を計画する必要がある将来のどこかでボトルネックにぶつかります。
多くのプロSVNコメントを見てきましたが、それらはすべて「SVNの方が良い」というよりも「SVNが悪くない」という性質のものである傾向があります。そのため、プロジェクトに分散バージョン管理(Gitなど)を選択することを強くお勧めします。
SVNに対するGITの編集の利点
誰かがSVNに固執する理由として、ツール(ビジュアルスタジオ用)に言及しました。http://gitscc.codeplex.com/は、Visual StudioのGITサポートを提供します。
Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.
私はこれに完全に同意しません。状況によっては認識される利点があるかもしれませんが、svnのバージョン番号が人間が読み取れるような単純なものは、多くの組織で大きな利点です。
当時Subversionを使用する特定の理由がありますか
IDEでのツールのサポートは別として(私は使用していません)、そうでもありません。もちろん、SVNはより親しみやすいかもしれませんが、それが唯一の理由であり、HgとGitの両方を非常に簡単に(そして非常に高速に)学ぶことができました。
はい、ブランチがヒルベルト空間の部分多様体をマッピングする単なる同相内在関数であると理解すると、Gitがいかに簡単であるかを説明する複雑なガイドがすべてあります。1
分かりません。しかし、あなたは何を知っていますか?関係ありません。Gitを使用するために、これらのことを知る必要はありません。
ほとんどの場合、GitとHgは使いやすく、SVNよりも明確な利点があります。部屋の象はもちろん枝分かれしています。枝はGitとHgで動作します。それとは対照的に、SVNでは、せいぜい痛みがあり、最悪の場合は破損します(複数のヘッドのマージ)。
もちろん、まだSVNを使用できます。Windows XPを引き続き使用することもできます。ただし、両方を試したユーザーの大多数は、代替案の1つが非常に優れていることに同意します。
1はい、これは冗談だとわかります。おもう。