gitなどの分散バージョン管理システムを使用し、共有フォルダーマシンを使用して参照リポジトリを保存します。その理由は次のとおりです。
各クローンはバックアップです
サーバーのハードドライブがクラッシュした場合、全員がコピーを取得し、新しいドライブまたはサーバーに展開する準備ができます。あなたの会社はバージョン管理について真剣ではないので、バックアップについてもほとんど同じだと思います。
共通のリファレンス
マスターブランチのあるメインリポジトリを使用すると、最後の単語があるバージョンを知ることができます。これにより、「あなたはフランクのバージョンに対して変更をテストしましたが、ジョンのバージョンも持っていましたか？それをどのようにマージしましたか？」を解決します。
より快適に配信
顧客は今日アルファ版を望んでいますか？マスターが十分に安定しているかどうかをテストして、それを出荷できます。そうでなく、修正する時間がない場合は、時間をさかのぼって、古いがより安定したバージョンを入手してください。最新バージョンしか持っていない場合はできません。
過去に戻って間違いを修正する
手動マージには、数日後にしか見られない問題がありましたが、共有フォルダーの内容はすでに上書きされていますか？VSCがないと履歴がないため、犯した間違いを確認して修正できるポイントに簡単に戻ることはできません。コードは写真のようなものではなく、映画のようなものです。時間とともに進化します。ムービーから画像を抽出できます。写真からムービーを抽出することはできません。
バグをより簡単に見つける
バグが発生しましたが、導入時には気が付かなかったため、コードが「ホット」である間は修正できませんでした。今では、どの変更がそれを導入したのか本当にわからないので、コードのいくつかの異なる場所から来る可能性があります。探す場所を見つけるのに何時間もかかります。gitを使用git bissectすると、特定のバージョンでバグが発生したかどうかを確認するテストを開発し、バグを導入した正確なコミットを見つけることができます。数千行のコードを探す代わりに、10行の変更にあることがわかります。テストスイートにテストを保持して、バグが再び発生しないようにすることができます。
各開発者は自分の仕事に責任を負います
あなたがチームリーダーであり、VCSがない場合、ほとんどの場合、汚い作業、マージを行う必要があります。自分でそれを行う場合、おそらくすべての変更についてすべてを知っているわけではなく、エラーが発生する可能性があります。逆に、マージするコードがあるたびにコードを書いた人にいつもあなたと一緒に集まるように頼むなら、それは彼らが新しいコードを作るのに使わない時です。
VCSを使用すると、シンプルなワークフローで、開発者は自分の作業と、変更の外部ソースの1つであるmasterブランチのみを処理するだけで済みます。masterブランチには、1人または100人がコミットしている可能性がありますが、それは同じです。自分の変更をプッシュできるようにするには、他の人が行った最新の変更にそれらを適応させる必要があります。コードをプッシュするのに時間がかかるように思えるかもしれませんが、それは、とにかく時間がかかるはずのマージも実行しているためです。
違いは、変更を行った人によってマージが行われることです。変更を行った人は、コードを書いたのでそのコードを最もよく知っています。
誰がそのコードを書いたのですか？
ここにはそのバグがありますが、その特定のコード行を誰が書いたのでしょうか？特にプロジェクトが数ヶ月続く場合は、覚えにくいです。git blameその行が誰といつ書かれたのかを教えてくれるので、適切な人に尋ねることができます。
プロジェクトは大きくなっています
顧客はより多くの機能を望んでおり、あなたはチームが小さすぎるため、別の開発者が必要になります。VSCなしで増加したマージの複雑さをどのように管理しますか？
緊急の変更
顧客は本番用の重大なバグ修正を要求しましたが、現在、あなたは新しい機能に取り組んでいます。ただ、git stash脇変更内容を置くか、新しいブランチにそれらをコミットし、変更をプッシュして、あなたの保留中の作業を失うことを恐れることなく、緊急の修正で作業を開始する準備が整いました。
10分前に機能しました
ローカルでいくつかの変更を行っており、10分前に機能していたものが機能しなくなりました。VCSがなければ、コードをじっと見つめるか、せいぜい参照バージョンのコピーを作成して、変更内容を確認するだけです。ああ、作業を開始してから参照が変更されたので、もう差分はできません。そして、変更の基にしたコードの原始的なコピーを保持することは考えていませんでした。
VCSを使用すると、すぐに次のような操作を行うだけgit diffで、ベースとなる適切なバージョンのコードと比較して変更が加えられます。
デバッグログを保存する必要があります
あなたは悪者であり、ロギングを使用しないのですか？printfその厄介なバグのすべての部分を見つけるまで、すべてのコードベースにs を振りかける必要がありましたか？今、あなたはそれを見つけて修正しましたが、慎重に作成されたデバッグコードを残して残りの問題を修正したいと思います。
VCSを使用しない場合、ファイルをコピーし、デバッグコードを削除して（編集エラーを追加する可能性があります）、それをプッシュし、バックアップファイルを戻す必要があります。ああ、とにかくデバッグ用のコードが入っているようです。
gitのでは、あなただけのgit add --patch、あなたのコミットに入れたい数行のコードを選択し、コミットできるだけのことを。その後、作業を再開し、デバッグコードを保持します。コードを変更する必要がないため、コピー/貼り付けエラーはありません。
泥の大玉
VCSがなければ、人々は自分の側で働き、時には関係のない多くの変更を行います。チェックするコードが多すぎる場合、バグを見つけるのは困難です。
VCSを使用すると、小規模な増分変更を行い、変更ログを提供できます。変更ログは不可欠です。人々は、変更が何であるかではなく、なぜ変更を行っているのかを説明する必要があります（コードの変更自体によって、どの質問が既に回答されています）。これは、たとえば、新機能のコードを調べているときに、無関係なバグ修正など、無関係な混合変更をたくさん読む必要がないことを意味します。これにより、重要なコードに集中できます。
100個のジャガイモを1つずつ与えると、1つが腐っていると、すぐに見つかります。今、あなたの前に100個のジャガイモを投げ捨てて、腐ったものを見つけるように頼んだら、それは同じ仕事ではありません。
くぼみ
良いコーディングスタイルポリシーがあることを願っています。そうしないと、インデントを変更すると、手動でマージした場合に夢中になります。もちろん、変更では空白を無視できます（ただし、Pythonのようなインデントがカウントされる言語では許可されません）。しかし、そうすると奇妙なコードが読みにくくなります。
あなたはプロジェクトリーダーです
あなたがリーダーである場合、これは、物事がうまくいかない場合、あなたが責任を負うことを意味します。適切なツールを適切な仕事に使用する価値があると上司がまだ理解できないために状況に満足できない場合は、少なくとも、予測可能な失敗のリーダーになることは拒否します。