ソース管理なしで複数の人でアプリケーションを開発する最も効果的/効率的な方法は何ですか？
私の状況の紹介
私は小さなウェブ開発会社で働いています。私も含めて、4人のASP.NET開発者のチームがあります。私たちのプロジェクトのほとんどすべて（> 98％）は、完了するまでに約1〜4週間かかる一人プロジェクトです。ソースやバージョン管理は使用しません。私たちが持っている唯一のものは、すべてのプロジェクトの最新のソース（==ライブアプリケーションのソース）を含むローカルサーバー上の共有フォルダーです。
まれに、複数の人と同じプロジェクトで作業する必要がある場合は、... Beyond Compareを使用します。 1日に1〜2回、コンパイルするバージョンがあるかどうかを開発者が互いに尋ね、Beyond Compareを使用してコードを同期します。 2人だけがプロジェクトに取り組んでいる場合、これは「かなり上手くいきます」が、3人目の開発者がプロセスに入るとすぐに、管理不可能なごみの断片になります。特に、誰もがデータベースに変更を加え始めたとき。
私（および仲間の開発者の1人か2人）は、Git、Mercurial、またはTFSなどの何らかの形式のソースおよびバージョン管理の使用を開始する必要があることを上司にすでに何度か伝えています（上司はMicrosoftを重視しています）。残念ながら、上司はソースとバージョン管理システムに切り替えることの利点を理解していません。なぜなら、彼の目にはすべて問題なく機能しており、新しいシステムのセットアップに時間とお金を費やして全員を確認したくないからです。それを使用する方法を知っています。彼に利点（簡略化されたコラボレーション、アプリケーションの異なるバージョン、コードを変更するためのより安全な方法など）を説明した後でも、彼はそれが私たちに必要なものだとはまだ思っていません。
4人の開発者のうち、2人（私を含む）だけがソース管理（Git）の経験があります。そしてその経験は非常に限られたものです。コンピューターにGithubリポジトリのクローンを作成し、変更を加えてコミットし、Githubにプッシュする方法を知っています。それでおしまい。
私の問題/懸念の説明
数週間以内に、私たちの標準のかなり大きなプロジェクトに取り組み始めます。それを完了するには、おそらく2〜3人の開発者が数か月かかるでしょう。私はプロジェクトリーダー（プロジェクトマネージャーおよびリードデベロッパー）となり、すべての責任を負います。私はBeyond Compareアプローチで問題を抱えていましたが、私の責任であるこの大きなプロジェクトでこの道を進みたくありません。
できるとは思えないので
- 独自のGitサーバーをセットアップします。
- すべての人にGitを使用するように教え、
- この大きなプロジェクトでGitをうまく活用し、
ソースまたはバージョン管理を使用せずに、複数の人が同じプロジェクトで共同作業できるようにするためのいくつかの良い方法を知っている人がいるかどうか興味があります。
更新
皆さまの回答とコメントに感謝いたします。ここに計画があります：
- 開発者とミーティングを行い、すべての技術者がソース管理の実装について同じように感じることを確認してください。誰もがその背後にいるとき、私たちはより強い主張をします。
- アイデアを上司に提示し、私たちが本当に必要ソース管理であることを伝えます。
- できるだけ早く実装してください。
1日かけてバージョン管理をインストールし、プロジェクトのすべての人にバージョン管理の使い方を教えてください。それほど難しいことではありません。個人的には私はGitを使用していませんが、他のバージョン管理システムをセットアップして使用しており、それらを動作させるのはそれほど難しくありません。開発環境と統合できるものを選択してください。これにより、実質的にシームレスに使用できます。
これは無駄な時間ではありません。
誰かが一部のコードを上書きまたは削除したときにwillが失われる時間は、はるかに高くなります。
バージョン管理がない場合は、プロジェクトのバックアップに膨大な時間を費やし、誰がどのバージョンを持っているか、どのバージョンがサーバー上にあるかなどを心配することになります。
上司を説得する必要がある場合は、バージョン管理以外のソリューションをセットアップして監視し、失われた作業を数日間書き換えるコストを追加するのにかかる時間を見積もります。同じソースファイルで作業している3人の開発者による編集を手動でマージするコストと、そのマージを誤る余分なコストを追加することを忘れないでください。適切なバージョン管理により、これをfreeで実現できます
次に、それをバージョン管理の取得のコストと比較します-nil（オープンソースに行く場合）とそれを設定する-3人日。
プロジェクトの後半のエラーは、早い段階で複数のコストがかかることを忘れないでください。誰かが間違いを犯してプロジェクト全体をやり直さなければならない場合、コストはfar書き換え時間だけではなく、上司の評判を損なう可能性があります。
フォルダーでソースを共有する場合は、そこにあるリポジトリも共有できます。ボスは、そこに.gitフォルダーがあることを除いて、それを知りません。
適切に仕事をするために許可を求める必要は決してないはずです-セス・ゴディン。
ソース管理をセットアップし、それを使用する方法を学び、上司に知らせないでください。私は通常、管理に反することを主張しませんが、この場合、あなたの上司は愚かです。 gitの学習に時間がかかりすぎると本当に思う場合は、svnのようなよりシンプルなバージョン管理システムから始めてください。gitが行うすべての優れた機能を実行するわけではありませんが、基本的な理解を得るのはさらに簡単です。
何かを実装する前に、その真ん中になり、深刻な問題が発生するまで待ってはいけません。ちょうどそれをし、仕事を成し遂げる。
追加のために編集：あなたの質問が本当に求めているのは、「ソース管理システムを使用せずにソース管理を行う方法」です。あなたは必要性を認識しました、そして私はここの誰もが本当にあなたに同じことを言っていると思います：ソース管理システムなしでソース管理を行うための健全な方法はありません。
私はあなたの要約だけを説明しますが、それから上司は時間とお金の議論をしているように見え、技術的な優位性の議論をしているようです。あなたは時間とお金の議論をする必要があります。 gitの方法を学び、しばらくの間それを節約できる時間を追跡します。その後、「3/28/2011は、Joeがコンパイル可能なビルドに戻るまで30分待つ必要がありました。したがって、マージを実行できるため、最後のコミットに対するgit mergeコマンドは約5秒でした」と、ニースの合計が下部に表示されました。
サーバーのトレーニングと設定がビジネスの障害である場合、「サーバー」の共有フォルダーを使用して実際にgitを使用するチームメンバーを1人だけにするなど、gitワークフローを設定する方法は無数にあります。
共有するのが適切な場合は常に、特定の共有フォルダーにコードをコピーするように同僚に指示します。それぞれのリポジトリを維持し、すべてのソース管理の作業を自分で行うことができます。それらをトレーニングするのに十分な自信が持てるようになると、徐々にソース管理の責任を徐々にそれらに渡します。これは理想的な方法とはほど遠いですが、現在の方法と比較すると、マージの時間を節約できます。少ないチーム学習曲線で上司を説得するのが簡単になり、必要なすべてのロールバックとバージョン管理の利点を得ることができます。
データベースの作業はあまりしていませんが、私の知る限りでは、データベーススキーマの変更のマージは、ソース管理ではうまく処理されません。これらのマージが困難な場合は、データベースのすべての変更が単一のゲートキーパーを通過するプロセスの変更を検討することをお勧めします。
これは非常識です。自分で作業する場合でも、VCSを使用する必要があります。会社でVCSを使用しないことは禁止されるべきです。早くやれよ。たった今！本当に...最初から高度なものは必要ありません。 GitHubとGitLabは非常に簡単に使用できますが、上司が要求した場合（WindowsでGitを設定して使用することは難しくありませんが）、Windows互換のホスティングサービスを見つけることができると思います。
あなたが尋ねると思うことは不可能です。ソース管理を使用せずに複数の人が同じプロジェクトで作業している場合、すぐに多くの問題が発生します。また、あなたがリード開発者であるため、あなたそれらに対処する必要があります。
私の個人的な経験から、ソース管理なしでプロジェクトに取り組むことは 2人の開発者から不可能になります。 ３つじゃない。 4つじゃない。二。 いくつかの例外的な状況で2人の開発者と一緒に状況を管理できるかもしれません：それらの開発者が非常に組織的で専門的である場合、彼らがうまくやり取りできれば、簡単に交換できれば（そうです）同じ部屋の同じ時間に毎回）、人為的エラーを回避できる場合（誤って別の人が同時に変更したファイルを誤って変更し、その人が行った変更を消去する）。
私の場合、2人をバージョン管理なしでプロジェクトに参加させることになると、それは常に多かれ少なかれ災害でした。最良のケースでは、1人が変更されたファイルを2番目のファイルに送信し、この2番目の人は差分ツールを使用して手動で変更を適用しました。最悪の場合、1人が自分が行った変更を追跡し、2人がソースコードを変更するたびに変更を適用しました。結果：時間、お金、生産性の大きな損失。
さて、私の見解と私自身の経験から、私はあなたが抱えている問題に対する3つの解決策を見つけました。
使いやすいバージョン管理をインストールします。 CollabNetSubversionをSVNサーバーとしてインストールするために使用しましたが、非常に高速で簡単にセットアップできます。セキュリティにまったく関心がない場合。 Visual Studioを使用する場合は、AnkhSvnをインストールして、開発者がVisual Studio内からソースコードを簡単に更新/コミットできるようにすることができます。
上司を説得するジョエルテストは自分の仕事をよく知っている人が書いたものであり、ジョエルテストがバージョン管理を提案している場合、その背後には十分な理由があります。結局のところ、コードを書くために開発者がIDE /構文の強調表示ツールを必要としないと決定することもできます。 Windowsのメモ帳で十分ですよね。また、なぜインターネットにアクセスできるのですか？必要なのは、Windows 3.1を実行している非常に古いPCだけです。
この会社をやめます、バージョン管理以外のすべてが完璧でプロフェッショナルなものであることに疑いがあるので。
大規模なプロジェクトでVCSを使用しないのは、セットアップに時間をかけたくないため、裸足で長い旅をするようなものです。靴を履く時間をかけたくないからです。
VCSは、まったくない場合よりも桁違いに優れています。
VCSを設定する非常に簡単な方法は、 TortoiseSVN を取得することです（C＃を使用しているように見えるため、Windowsを使用していると想定しています）。選択したローカルフォルダーにリポジトリを作成します（そこに移動し、右クリック> TortoiseSVN>ここにリポジトリを作成）。このフォルダーをネットワークで共有し（できれば、常に使用可能なマシン上にあることが望ましい）、URL file://computername/path/to/that/repositoryでチェックアウトします。ダウンロードは除外されました。これはセットアップに1分もかかりません。
あなたの答えは上司への簡単なリンクです...このページを上司にメールで送信し、専門家から「辞める」という言葉が現れる回数を強調してください。
「ダム」という言葉はおそらく何度も出てきますが、あなたの上司はいないと思います。彼にとって、これの絶対的な価値は明らかではありません。彼に尋ねる質問は、どのようなビジネス関連の質問が同じ応答をもたらすかです（おそらく、会計士が「あなたが最大に拘束されていることをこの建物に保証しないでください、数ドル節約できます！」）。
ソース管理は、プロジェクトの開発者の数が0より大きい場合にのみ必要です。継続的インテグレーションについても同じことが言えると思い始めています...
（-：
あなたはASP.NET開発者なので、Subversion、TFS、またはMercurialのいずれかを使用することをお勧めします。ただし、正直に言うと、何かを使用している限り、どちらでもかまいません。バージョン管理なしで開発することはまったく意味がありません。ツールが多かれ少なかれ自由に展開でき、それらを使用するためのオーバーヘッドが最小限の場合はなおさらです。
TFSは驚くべきレベルの統合を提供します。 DVCS（Mercurialまたはgit）は、おそらく最も柔軟性と機能を提供します。これを行わない理由はありません。
私がゼロから始めたとしたら、それはほぼ確実にMercurialを使用することになります。
バージョン管理ができたら、ビルドサーバー（TFS、TeamCity）に進み、そこから継続的な統合に進むことができます。その時点で、最初からやり直すことができます。
出発点に戻るには：
私はプロジェクトリーダー（プロジェクトマネージャーおよびリードデベロッパー）となり、すべての責任を負います
あなたはバージョン管理が必要だと判断します（そうするため）、あなた（必要なため）ビルドサーバーが必要であると判断し、youからプロジェクトからデプロイ可能な出力が必要であると判断します初日（常に展開できるため、より多くのテストが容易になるため）および展開が高度に自動化されるため-これらは、プロジェクトの成功を保証するために実行している手順です（担当します）。 。）
Gitのような分散バージョン管理システムを使用し、共有フォルダーマシンを使用して参照リポジトリを保存します。理由は次のとおりです。
各クローンはバックアップです
サーバーのハードドライブがクラッシュすると、全員がコピーを取得し、新しいドライブまたはサーバーに展開できるようになります。あなたの会社はバージョン管理について真剣ではないので、バックアップについてもほとんど同じだと思います。
共通リファレンス
マスターブランチのあるメインリポジトリがあると、最後のWordのバージョンを知ることができます。これにより、「フランクのバージョンに対して変更をテストしましたが、ジョンのバージョンもありましたか？そして、どのようにマージしましたか？」を解決します。
より快適に配信
顧客は今日アルファ版を求めていますか？さて、マスターが十分に安定しているかどうかをテストし、それを出荷できます。そうではなく、修正する時間がない場合は、時間を遡って、より古いがより安定したバージョンを入手してください。最新バージョンしかない場合はできません。
時間をさかのぼって間違いを修正する
手動マージで問題が発生したのは数日後になってからですが、共有フォルダーの内容は既に上書きされていますか？ VSCがないと、履歴がないため、間違いをチェックして修正できるポイントに簡単に戻ることはできません。コードは写真のようなものではなく、映画のようなものです。時間とともに進化します。動画から画像を抽出できます。画像からムービーを抽出することはできません。
バグをより簡単に見つける
バグが発生しましたが、導入された時点では気付かなかったため、コードが「ホット」である間は修正できませんでした。どの変更がそれを導入したのか本当にわからないので、コードのいくつかの異なる場所から発生する可能性があります。どこを見ればよいかを見つけるのに数時間かかるでしょう。 gitを使用すると、特定のバージョンでバグが発生するかどうかを確認するテストを開発し、git bissectバグを引き起こした正確なコミットを見つけます。数千行のコードを探す代わりに、10行が変更されていることがわかり、テストスイートにテストを保持して、バグが再び発生しないことを確認できます。
各開発者は自分の仕事に責任があります
あなたがチームリーダーであり、VCSを持っていない場合は、おそらくダーティーな作業であるマージを実行する必要があります。自分で行う場合、おそらくすべての変更についてすべてを知っているわけではなく、エラーが発生する可能性があります。反対に、コードを書いた人に、マージするコードがあるたびに一緒に集まるように頼むと、彼らは新しいコードの作成にそれを使わなくなります。
VCSを使用すると、単純なワークフローで、開発者は自分の作業と、変更の1つの外部ソース（マスターブランチ）を処理するだけで済みます。 masterブランチでは、1人または100人がコミットしている可能性がありますが、これも同じです。自分の変更をプッシュできるようにするには、他の人が行った最新の変更にそれらを適応させる必要があります。コードのプッシュには時間がかかるように思えるかもしれませんが、それはとにかく時間がかかるマージも実行しているためです。
違いは、マージは変更を行った人によって行われるということです。コードを書いたので、そのコードを最もよく知っている人がマージを行います。
誰がそのコードを書いたのですか？
ここにはそのバグがありますが、その特定のコード行を書いたのは誰ですか？特にプロジェクトが数か月続く場合、覚えるのは難しいです。 git blameは、誰がいつその行を書いたかを教えてくれたので、適切な人物に尋ねることができ、「それを書いた覚えがない」ことはありません。
プロジェクトは大きくなっています
顧客はより多くの機能を望んでおり、チームが小さすぎる場合は、別の開発者が必要になります。 VSCを使用せずにマージの複雑化をどのように管理しますか？
緊急の変化
お客様から電話でプロダクションの重大なバグ修正を依頼されましたが、現在、新しい機能に取り組んでいます。ただgit stash変更を保存するか、新しいブランチにコミットして変更をプッシュすると、保留中の作業を失うことを恐れずに緊急修正に取り掛かる準備が整います。
それは10分前に働いた
ローカルでいくつかの変更を行っており、10分前に機能していたものが機能しなくなった。 VCSがない場合は、コードを凝視するか、せいぜい参照バージョンのコピーを作成し、diffを実行して変更内容を確認します。ちょっと待って、作業を始めてから参照が変わったので、もう差分できません。また、変更の元となったコードの元のコピーを保持することは考えていませんでした。
VCSでは、git diffすぐに、そしてあなたが基づいているコードの正しいバージョンと比較してあなたの変更があります。
デバッグログを保持する必要があります
あなたは悪者であり、ロギングを使用しないのですか？厄介なバグの断片がすべて見つかるまで、すべてのコードベースにprintfsを散らす必要がありましたか？今、あなたはそれを見つけてそれを修正しましたが、残りの問題を修正するために慎重に作成されたデバッグコードを保持したいと思います。
VCSがない場合は、ファイルをコピーし、デバッグコードを削除して（編集エラーが追加される可能性があります）、それをプッシュして、バックアップしたファイルを元に戻す必要があります。ああ、でもとにかくデバッグコードが入ったようです。
Gitでは、git add --patchして、コミットするコードの数行を選択すると、コミットできますonly。その後、作業を再開しても、デバッグコードは残っています。コードに手を加える必要がないため、コピー/貼り付けエラーは発生しません。
泥の大玉
VCSがないと、人々は彼らの側で働き、時には無関係な一連の変更を与えます。チェックするコードが多すぎると、バグを見つけるのが難しくなります。
VCSを使用すると、小さな増分変更を行うことができ、変更ログが提供されます。変更ログは不可欠です：人々はそこに伝える必要がありますなぜ彼らは変更を行っているのではなく、whatが変更です（whatの質問はすでに回答済みです）コード変更自体によって）。これは、たとえば、新機能のコードを検査しているときに、無関係なバグ修正などの無関係な混合変更をたくさん読む必要がないことを意味します。これにより、気になるコードに集中できます。
じゃがいもを1つずつ100個あげると、腐っているとすぐに見つかります。今、私があなたの前に100個のジャガイモを投げて、腐ったものを見つけるように頼んだとしても、それは同じ仕事ではありません。
インデント
あなたが良いコーディングスタイルポリシーを持っていることを願っています。さもなければ、手動でマージするとインデントの変更が狂ってしまうでしょう。もちろん、変更の空白は無視できます（ただし、Pythonのようにインデントがカウントされる言語ではできません）。ただし、奇妙に見えるコードが読みにくくなります。
あなたはプロジェクトリーダーです
あなたがリーダーである場合、これは、物事がうまくいかなかった場合に非難を受けることを意味します。上司が適切な仕事に適切なツールを使用する価値があることをまだ理解できないために状況に慣れない場合は、少なくとも、私は予測可能な障害のリーダーになることを拒否します。
チームにバージョン管理を採用するように説得できない場合や、上司が控えめな態度をとってチームを止めるように要求した場合、最適とは言えないアプローチをとることができます。
自分のマシンにGitまたはMercurialをインストールします。自分の作品にバージョンを付けます。チームがBeyond Compareプロセスを介して作業を同期したら、変更をローカルリポジトリに新しいコミットとして追加します。チームの同期で何かが壊れた場合でも、ローカルリポジトリから以前の作業バージョンをいつでも取得できます。
DVCSを使用すると、サーバーや複雑なセットアッププロセスが不要になります。 Mercurialをインストールし、基本を使用して実行するには、約30分かかります。
これは理想的なソリューションではありませんが、何もしないよりはましです。
上記のように、既存の共有フォルダにリポジトリを置くことができます。 Git、Mercurial、Bazaarなどの分散ソース管理システムを使用すれば、サーバーの構成に時間を費やす必要はありません。
すでにGitを使った経験があるので、Gitを使用するか、Visual Studioにうまく統合されているMercurialを使用することをお勧めします。
将来、上司からTFSに切り替えるよう指示された場合でも、バージョン管理をまったく行わないよりはましです。
私のPowerbuilder時代には、チーム全体がソース管理を使用せずに一連のアプリケーションに取り組んでいました。ああ、Powerbuilder hadソース管理ですが、実際にはsingこれはクラックシュートでした-ファイルをチェックアウトしているときにPBがクラッシュした場合（そして、LOTがクラッシュした場合）は、バイナリソースコードファイルにアクセスできなくなりました。一部のフラグがファイルに設定され、他のPBのコピーはそれをロードできませんでした。それをチェックアウトした人と同じです。
だから私たちがしたことは非常に簡単でした。 「ねえ、トム、私はxyz.pblで作業します。変更しないでください。」物事の壮大な計画では、問題はほとんどありませんでした。
これに対する私の最初の反応は、バージョン管理のない理想的な作業プロセスがすでにあるというものでした。あなたは皆、マージなどを管理する良い方法を持っているようです。管理上の観点から、これは一見良い状況のようです。バージョン管理を使用するチームに出会いましたが、開発プロセス自体と格闘する必要があります。
したがって、そのバージョン管理に基づいて上司だけを説得しても、「より良いプロセス」が得られることはまったく無意味です。ただし、なぜ最初にバージョンまたはソース管理を使用する必要があるのかについて、別のはるかに重要な引数があり、簡単に計算できます。そしてそれは：
危険
問題は、ソース管理を使用すると開発プロセスが改善されることではありません。ソース管理がまったくない場合、どうなるかは問題です。リスクは何ですか？
コード内の関数またはファイル全体を誰かが誤って削除したとしましょう。修理にいくらかかりますか？うまくいけば、誰かがそれをカバーしているので、修正は限界です。
しかし、失われたファイルのバックアップを持った人がいない場合はどうなりますか？それを修正するのにどのくらいの工数がかかりますか？それはおそらく数日かかるでしょう、そしてそれは簡単に平均労働時間で計算されます。それは会社にとって多すぎるでしょうか？これは何とか早く修正できますか？
はい、なんらかのソース管理があります。対照的に、バージョン管理を設定してバックアップするのにどのくらいの時間がかかりますか？ gitやMercurialなどのオープンソースのほとんどは、セットアップにそれほど時間はかかりません。 Beyond Compareとマージする方法をすでに知っており、共有フォルダーに「チェックイン」することを考えると、それを使用する方法を教えるのはそれほど難しくありません。これは、1回限りのセットアップコストです。これらの工数は、リスクのある工数よりも短いでしょうか？これに該当する場合は、ソース管理の使用が優先されます。
ソース管理が有用であるビジネス上の理由を示すことができ、リスク管理がそのような大きな要因の1つである限り、ほとんどのボスは納得するでしょう。