平均的な企業の大規模プロジェクトには、どのようなソース管理が必要ですか？[閉まっている]

Gitはオープンソースプロジェクトに最適です。しかし、私は疑問に思っていました。1年間のプロジェクトに取り組んでいる20人のプログラマーがいる企業にとって、どのソース管理システムが望ましいのでしょうか。私が聞いたところによると、Gitはプルを使用しています。メイントランクで変更を取得するために他の誰かを経由する必要があるのは望ましいことではないでしょうか。特に全員が同時に作業している場合はどうでしょうか？

それは私が疑問に思っていた例の1つにすぎません。私はSVNの使用方法を知っていますが、すべての作業がPHPで行われ、通常はスタンドアロンの1週間のプロジェクトだったため、最後の仕事でさえプロジェクトで使用しませんでした。私はローカルコード用のSVNを持っているだけで、他の人と一緒に使用する必要はありませんでした。

それでは、優れたソース管理とは何ですか。具体的にはなぜこれに適しているのでしょうか。

チームが使いやすいものを使用してください。すべてのバージョン管理システムは、ほぼ同じことを同じように実行します。「うまくいくかもしれない」ので、ホイールを再発明する理由はありません。チームが何にも慣れていない場合は、チームの標準IDEと最も簡単に統合できるオプションを選択してください。

Mercurialは優れており、配布されており、無料です。

どれだけのサポートが必要かによると思います。

私は自宅で楽しいプロジェクトにgitを使用していますが、問題が発生すると時間がかかりますが、修正に必要なことを学ぶために時間を費やすことができます。

24時間年中無休のテクニカルサポートが不可欠であるため、職場ではPerforceを使用しています。私たちは常にニューヨーク、ドイツ、アイルランド、そして日本でコードに取り組んでいる人々を抱えています。問題がある場合は、早急に回答を得る必要があります。私の経験では、PERFORCEの人々は彼らが何をしているかを本当に知っており、提案を受け入れます。

この質問は広範であり、ITフレームワークとネットワーク/開発構造に基づいて、会社ごとに対処する必要があると思いますが、ソース/バージョン管理を選択する際の最も重要な側面は、使用するアプリケーションではないと思います。しかし、それが使用されるかどうかは、実際に構造化され、強制されます。

使用法の構造と実施は、バージョン管理の最も重要な側面です。

事前に計画し、全員を参加させます。使用を強制します。プログラマーだけでなく、プロジェクトに関連するすべてのもの（ドキュメント、イメージなど）を使用します。

SVNはすばらしいアプリケーションであり、多くのアドオン（バグ/タスクトラッキングを含む）と統合でき、個別のサーバーを必要とせず、無料です！

@EricBoersmaが言ったように、他にも優れたソース管理アプリケーションがあります。

チームが使いやすいものを使用してください。

プロセスとベストプラクティスを用意し、それを実施できるプロセスから購入するだけです。

gitの動作について、いくつかの大きな誤解があります。プルリクエストをゲートキーパーに送信することは、それを行う唯一の方法です。これを設定する方法は他にもたくさんあります。たとえば、svnとほぼ同じです。これは、カスタマイズするのに十分な快適さを得る前に、多くの人が最初に始める数です。gitのようなDVCSを使用すると、ワークフローの周りではなく、ワークフローの周りにソース管理を構築するための十分なオプションがあります。

私は以前、ソース管理は単なるツールであり、各製品は多かれ少なかれ同じことをしたと思っていました。そして、これらの分散バージョン管理システムのポイントが私と一緒にクリックされました。

分散バージョン管理により、複数の中央リポジトリを使用できます。ローカルの開発者リポジトリ、機能リポジトリ、製品リポジトリ、QAリポジトリ、そして最後にリリースされたリポジトリに移行するコード変更を想像してください。

個人的には、HgベースのKilnという商用製品を使用していますが、主な機能は分散バージョン管理です。開発者からリリースされた製品への新しいコードの流れに革命をもたらします。

あなたはSVNを使用する方法を知っていて、次にSVNを使用します-必要なものがある場合のみ、DVCSに移行してください。

本当に重要なのは、使いたいものを使いやすく、使いやすいということです。Martin FowlerがVCSについて簡単な調査を行いました。結果は非常に興味深いものです。

私は最後の仕事でgitを設定しましたが、同じサイズのプロジェクト（15人の開発者、18か月のプロジェクト）で作業していましたが、うまくいきました。

設定方法は次のとおりです。

一元化された権威のあるgitサーバーであるgitサーバーがありました。すべての変更が中央サーバーに入るように、チームメンバーは互いに直接プルすることはできませんでした。

マスターブランチをメインの本番ブランチとして使用し、リリースごとにタグを付けました。プロジェクトの各モジュールはgitサブモジュールでした。各サブモジュールには、チームメンバーごとにブランチがありました。メンテナ（通常は元の作成者）が各サブモジュールに割り当てられ、他のチームメンバーからのプルリクエストを処理し、準備ができたときにメインブランチのサブモジュールを更新するチームリーダーにプルリクエストを発行しました。本番ブランチに統合されます。特定の機能を完了した、またはリリースに対応したコミットを識別するために、タグを使用しました。

私は少なくともMicrosoftのTeam Foundation System（TFS）をよく見ています。私はあなたがマイクロソフトショップではないとあなたのコメントからとっています。しかし、私の理解は、開発にそのIDEを使用する場合、かなり堅牢なEclipseプラグインがあるということです。

マージとブランチのメカニズムは他のソース管理システムと同じように機能しますが（私の経験ではsvnよりも優れており、perforceと同じくらい優れています）、実際に優れているのは、製品のプロジェクト追跡とプロジェクト管理の側面です。ビルドとデプロイメントのための組み込みの自動化。

Webベースのアプリケーションを作成している場合は、自動化されたUIテストフレームワークと、かなり短時間で構築および構成できる負荷テストフレームワークを見てください。洗練された機能の1つ：負荷テストに組み込まれたモバイルブラウザーのシミュレーション。