まず、私は基本的な立場を示して、私は個人的にgitを使用することを好むが、これは単なる個人的な好みです。私たちは技術的な解決策が必要な場合は、チームの選択、プログラムの会社より効率的なのではない意思決定の大きな要因として、私たちの個人的な好みによって、チーム全体をもたらすために、しかし、バランスをとるのに十分であるべきです。個人的な観点、長所と短所の合理的な評価を脇に置き、私は認識かもしれないシニアプログラマー、建築家や義務です。
私が今だった、とチームは、我々は5つ以上のプログラミング言語、4周りのメンテナンスプロジェクトの開発を使用して、約20プログラマの合計を持って全社のgitのバージョンコントロールシステムなどの技術的な解決策の選択肢である、小さなスタートアップ企業であります上位中規模企業に研究開発しました。私はgitのが好き、と言ったので、私は会社に入社する前に、バージョン管理システムGitリポジトリを使用して、すでに既成事実ですが、私はこれを聞いて、私は、とても幸せでした。
金曜日に、私たちの新しいエンジニアが毎週の会議のgitで共有するために、同僚が道路に挑戦し、なぜGitはSVNのよりも良いですか？この質問は、私は個人的に、私は思考の私の通常モードのように、他人を説得するために、それは十分な説得力のある理由が与えられなければならない、多くの理由であってもよいが、できるかどうかを尋ねられた、他人を説得するために主観的要素を使用することはできません、それは唯一の論争につながります。
この問題「より良いgitのSVNのはなぜ」、私は本当に答えを私の検索の過程で、明確な答えを与えたいと思った、しかし、のために、困難が発生しました。だから、私はその後、私たちは議論を有効にします、否定的な答えを与える立場に立ってみてくださいので、この記事の主題があります。
最終的にはSVNの利点は何ですか
幅広い国民の支持。私は、バージョン管理システムを使用し始め、私が使用してすでにSVNあるので、最後にあなたがウィキペディアに頼る必要があった際に、遡及的にSVNを開始したい、私は戻って2000年にまで遡る、SVNの最初の公式バージョンを見つけました、15年前にそれが歴史となっています。githubの大ヒットする前に、SVNは、基本的な位置に世界を支配します。ほとんどすべての企業が、バージョン管理システムとしてSVNを使用して、内部、Google Codeのは時間のために、オープンソースソフトウェアの波をオフに設定されている、世界中のほとんどのプログラマー、SVNを使用しています。
私たちは現在、プログラマーを募集していることを言ってみろ、まだSVNを使用したことがありません。これは、企業がSVNを使用している場合、その後、彼らはすぐに始める確率は、非常に高いことを意味します。今中国の中小企業や新興企業、プログラマーを雇うの難易度は、私は手の込んだしたくない - 責任者、頭痛誰 - あなたはSVNを使用する場合は、バージョン管理システムを学ぶことはこの種のものを使用して、あなたはの心ではありません問題。
優れたクロスプラットフォームのサポート。事の古い種類は、この観点クロスプラットフォームのサポートで常に不利ではない、それが支配的になります。十五年、SVNは、ほぼすべてのプラットフォーム上で優れたクライアントソフトウェアを得ました。Windowsプラットフォームの成功TortoiseSVNは、ほとんど言うまでもなく、とさえプログラマは、TortoiseSVNのSVN自体、小さなカメへの参照だと思うし、各コードは、農業心臓笑顔になります。また、SVNコマンドラインクライアント自体は、それは非常にシンプルで使いやすいとなっています。クロスプラットフォーム簡単かつうるさい任意の場所なし。
使いやすいです。私は個人的に使用SVNのしやすさは比類のないことを信じています。テンセントの新入社員の私の最初の年、周りのプログラマは、使用クラウドフォルダとしてSVNにあります。部門全体では、唯一の1つのリポジトリ、プロジェクトフォルダ、トランクコード内のすべての項目はまだトランクリガフォルダに新しいプロジェクトを開く必要があります。SVNはこの程度に誤用されている場合でも、それはまだ開発プロセス全体すべての主要なトラブルを持っていなかった、すべてが完璧な順序です。あなただけの小さなマウスの小さなカメで、つまり、学ぶ必要があります。
その後、部門は徐々に拡大し、増加したドキュメント、失われていない文書を保護するために、部門は、SVNサーバの独自の運用・保守を設定するので、SVN管理とSVNのドキュメント管理、要件の様々な設計案と非プログラマのすべてのメンバーは、すべて、すべて、切り替え処理はほとんどそれが少し訓練を受けたいくつかの非技術的な同僚を与えるために、単純である、任意の時間を費やしていないが、すべてがスムーズに例外があります。V.、60非技術的な人々、突然のすべては、それのシンプルさを示してSVNを使用していたしましょう。
完全に機能し、安定しました。ビューの過去7年間（この場合、2015）開発経験の観点から、私はSVNを扱うことができない任意のR＆D管理モデルを発生していません。特に、次のシーンでは、中国での株式会社R＆Dチーム管理。SVN自体は、開発プロセスのモデルを推奨トランクのための十分な、十分な十分なトランクコードを持って、機能開発のための枝、スナップショットを公開するためのタグは、すべてがスムーズで自然です。
私がいたチームは、探査やランニングの数年後に、非常に滑らかでスムーズな開発プロセスを形成しています。新しいオープンブランチにタスク、毎日、午前中にまず最初に、同期のトランクの変更（同期トランク）、タスクが完了すると、分岐テスト、回帰テストがトランク（社会復帰）が終了した後、統合テストの完了後、テストが渡され、遊びがあります。タグは、その後、内部の自己学習のオンラインシステムは、コードリリースの全体量をタグ付けし、ブランチの最後のヘッドは、使用ブランチを削除しました。マージ追跡機能が1.5 SVN後に出現し、特にでも競合が非常に偶然入射します。
SVNの研究開発、完璧な、と非常に安定した機能障害の約15年後、あなたはそれはほとんど常にあなたがよく知っているその状態を維持され、コマンドとパラメータに精通している、追加の学習費は、最も貴重なは、SVNは継続的に更新されていないが、効率を改善します。
SVNのGitは相対的に言って、欠点は何ですか？
学習のコストが高いです。ああ、あなたはシンプルで一人だけ、チーム全体を、またはあなたの場合、あなただけの、一人の人間の感情を表現することができると思うことを、この主観的な感覚を、「学ぶことは非常に簡単である」オープン目で、gitの学習は非常にシンプルであることを教えないでください。チームはエリート文化を追求しないエリートの募集はそうではありません、あなたのすべて、gitのを学ぶことは非常にシンプルであることを感じることがあります。それは、新たに起業家中小企業、または中小企業は、それ自体が市場から取得した才能の程度を考慮すると、数年前から動作している場合しかし、あなたは彼らの受け入れを考慮する必要があります。もちろん、企業が研修にエネルギーを費やすが、トレーニング時間やコスト、自身で構成することができ、「学習コストを。」
貧しいクロスプラットフォームサポート。Windowsの場合、特に非友好的なインチ ただし、Windowsはまだ世界で最も広く使用されているオペレーティングシステムであり、私は信じて、草の根プログラマーの大半は、まだWindows環境で動作し、gitのほとんど意図的なWindowsの非友好的な、私は最終的に何のためにあるのかわかりません。GitHubには関係なく、Windows上のgitを使用して、IDEのさまざまな何が行われたか、何が行われたか、その経験はまだ非常に間接的で不便ではありません。
悪い抽象的な、複雑な構造。良い使用のgitを作成するには、ユーザーがいくつかの非常に特別なことを理解する必要があり、分散型構造は、他のストレージの原則のgitのバージョンです。これは、彼の人々を理解する時ではない非常に友好的、あなたはほとんど直感的に混乱物事をほぼ常に、gitのを使用することはできません。また、設計案を管理するためにgitを使用しようと、このような当社のデザイナーとしてGitの作品を使用することはほとんど不可能、同社の非技術的な同僚、、、、と協力し、実際の経験は非常に悪いです、彼らも新しいリポジトリを作成しません。事実はもちろんのこと、また、バイナリファイルをgitのは、どのように友好的ではありません。
あなたは物事が非常に悪いことができます。ユーザーは自由の偉大度を与えて、システム全体をgitの、私たちが知っている多くの操作は危険ですが、オペレーティングシステムがあなたを停止しません。たとえば、たとえば、あなたがブランチをリベースするために多くの人々が共有する置くことができ、あなたはチーム全体の悪い信じられないほどの混乱ケアの多くを行うことができ、例えば、ローカルコミットの歴史をコミット削除するのは自由です、任意のブランチをプッシュする任意の枝を置くことができますスピード、あなたがトラブルに巻き込まれることができ、gitの自体は、任意の保護メカニズムを提供していません。
ない結論結論
私は完全にそれを説明するためのSVNのプロポンプ角を立て、私は上記のことを、いくつかのケースではSVN、Gitはより実際には、より適切な、と私は、この結論はまた、比較的公平であることを考えると結論します。R＆Dは、低コスト、小型のR＆Dチームは、R＆D人材の経験が変化する会社は、完全にあなたのチームの発展をたどる可能性が直接使用SVNを、考慮しなければならない場合は、多くの時間を節約。
もちろん、考慮すべき要因は、高周波数調整するかどうか、特徴およびコンテンツ開発プロセスの開発でありますか？クロスカンパニー、クロス地域連携かどうか？オープンソース・システムに関わる大規模なR＆D担当者がいますか？そして、私の経験では、いくつかの企業は、R＆Dチームは、SVNは自然に、より合理的な選択になるように、これらのものは、側面を取るソートしています。