その説明に当てはまる人の良い例は、プロジェクトマネージャーかもしれません。

先日、上司から「このGithubのことは何か、なぜ重要なのか」と尋ねられました。彼はいくつかの独自のプロジェクトを持っているので、プライベートホスティングが必要になります。私はいつも以上に説明するのに苦労しました。 。私の考えでは、「DRVSを使用して、それがどれほど有益であるかを本当に理解しなければならないかのようです」と考えていました。

最終的に私は彼に無制限のプライベートリポジトリを提供するため、BitBucketを指すようになりました（リポジトリとは何かを説明する必要さえありました）。

誰もがVCSがいかに彼らの命を救ったか、人生を楽にしたかなどの本当に良い具体的な例を持っていますか？基本的に、どのように職業にプログラマーではなく、プログラミングに不慣れではない人にDVSCを販売しますか？

バージョン管理は、（少なくとも）3つの4つの点で優れています：バックアップ、開発者間のコードの共有、バグの発見と修正、進行状況の追跡。

1. バックアップ。それ以外の場合は、ステロイドのバックアップです。開発履歴全体があります。各コミットは、ID（リビジョン番号）、説明、タイムスタンプ、ユーザー情報を含むコード全体のスナップショットです。また、リビジョン間でファイルを比較するのは簡単です。それ以外の場合は、単純なバックアップ（ファイルの変更のみが送信および保存される）よりも高速であり、はるかに有用なメタデータが含まれています。なぜこれを再発明するのですか？

2. 開発者間でコードを共有します。少なくとも2人の開発者が同じ製品で同時に作業している場合、コードの変更を確実かつ一貫して共有してそれらをマージする他の方法はありません。メールでzipを送信しますか？

3. バグの発見と修正。顧客が特定の製品バージョンのバグを報告すると、実際のソーススナップショットをすばやく取得して、それを再現および修正できます。ソースが顧客のものと異なる場合、バグを再現するのは困難です。実行可能ファイルを送信して、逆アセンブルできるように依頼しますか？さらに、バグの原因の特定に問題がある場合は、VCSを使用して、導入された正確なリビジョンを特定できます。

4. 進行状況の追跡。スナップショットで作業をコミットすると、機能の実装の進捗と未解決のバグのステータスを追跡できます。VCシステムは、追跡システムや継続的統合システムとも簡単に統合できます。VCSがなければ、趣味のプロジェクト以外の品質を維持することはほぼ不可能です。

あなたがまったくのソフトウェア開発がすべきことに合意したら、これまで VCS（私も趣味のプロジェクトのためにそれを見逃すことはありません）外で行われていないこと、そして、あなたは（少し複雑）DVCS露骨からコピーされます（次の一部の機能について説明することができますウィキペディア）：

• 各ユーザーは、リポジトリの独自のローカルコピー（および事実上、バックアップコピー）を持っています
• ユーザーがネットワークに接続していないときでも生産的に作業できるようにします
• ネットワークが関与しないため、ほとんどの操作がはるかに高速になります
• プロジェクト当局からの許可を必要とせずにプロジェクトへの参加を許可します
• プライベートな作業を許可するため、ユーザーは公開したくない初期のドラフトでもリビジョン管理システムを使用できます。
• 単一障害点として単一の物理マシンに依存することを回避

「「元に戻す」ボタンが便利だと思ったことはありますか？ああ、それではバージョン管理を使用することに同意しますか？」

バージョン管理を使い始めたとき、私が興味を持っていた主な機能は、ミスを「元に戻し」、前のバージョンに戻る機能でした。誰もが元に戻すボタンに感謝することができます。付与されたバージョン管理では、さらに多くのことができます。

基本から始めます。

まず、VCSは開発者を自分自身およびお互いから保護します-2人以上の開発者が同じコードベースで比較的安全に作業できるようにする以外の目的がなければ、大きな価値があります（そして、少しの不注意なコピーによって作業が上書きされた）。

次に、監査証跡-履歴-を提供し、誰が何をいつ変更したかを確認できます。また、不要になった、または適切でなくなった後で削除したコードに戻って取得できますすべて。

第三に、それはあなたに基準点を与えます-決定的なソースはコミットされたコードです（特にDVCSでは実際の世界では少し複雑ですが、この議論のために十分近いです）。リポジトリが適切にバックアップされている場合は、会社の資産を保護する必要があります。

これらの3つのことは、VCSを販売するための「それ」でなければなりません-マネージャーが上記の時間内に別のマネージャーを見つけるのに十分な価値を見ることができない場合。

VCS（結局、開発者の数が0を超える開発チームにのみ使用される）を販売したら、DVCSがSVNやTFSなどを経由する理由の問題と、動作するかどうかのさらなる問題社内で、またはKiln、Bitbucket、Githubなどのホストされたサービスを使用する（支払いを行うとプライベートになります）のは、かなり深く、コンテキストに依存します。

VCS

バックアップの概念を説明してください。バックアップを使用すると、特定の瞬間に作業していた内容を確認できます。VCSsプログラマーがプロジェクト全体を強制的にコピーする前に、一般的にはそれぞれの良い安定したリリースを保存する方法を教えてください。プロジェクトの2つのバックアップ全体ではなく、違いを見るだけで、彼らや他の誰かが台無しにして簡単に修正できます。

要約すると、 VCSを使用すると、作業のバックアップを保存し、バックアップ間の違いのみを表示することができます。

DVCS

分散バージョン管理については、典型的なバージョン管理がどのようにサーバーとインターネット接続を必要としていたかを説明し、それが遅くなり、誰もがそれを台無しにした場合、誰もが単一のバックアップに取り組んだため、誰もがそれに飽きたことを説明し、分散バージョン管理を使用すると、誰もがインターネットに接続せずに自分のマシンで自分のバックアップを操作できます。作業中に誰もバックアップを台無しにしないので、作業が終わった後に作業を共有することを心配することがないため、誰もが満足しています。

もう1つの良い点は、バックアップが1つしかない集中型VCSとは異なり、バックアップのあるマシンが発火した場合、他の完全なバックアップ（開発者ごとに少なくとも1つ）が残っていることです。

要約すると、 DVCS を使用すると、1台のサーバーに誰もが煩わされることなく、独自のバックアップで作業できます。また、作業が終了した後、他のユーザーの変更を心配できます。また、メインのリポジトリマシンが火災を起こしても何も起こりません。

私は主にエンジニアと仕事をしています（開発者自体ではありませんが、コードを書いています）

主なポイントは、バージョン管理について説明するとき、コード/ドキュメント/その他を取り消して管理し、他の開発者/ライターなどとのコラボレーションを簡素化できることです...

それは良いセールスポイントです-そして、すべての作業にVCSを使用する主な理由であり、他の利点もあります：履歴を持ち、簡単にバックアップできるレポ...

彼らのほとんどはこのアイデアを気に入っており、非常に有用であり、プロジェクトに採用しています（特に他のエンジニアとのコラボレーションが必要な場合）。

誰かに何かを納得させようとするとき、あなたは常に彼らの観点からそれに到達しようとする必要があります。

プロジェクトマネージャーの目標は単純で、プロジェクトを時間通りに予算内で完了することです。

現在バージョン管理を使用していない場合、開発チームはバージョン管理が手動で解決する問題を解決しています。これらの問題はすべて他の回答で十分に列挙されているので、ここでは取り上げません。

あなたがする必要があるのは、プロジェクトマネージャーに、チームがX毎週GITが自動的に解決できる問題を手動で解決するために何時間も費やしていること、または0.1 * X開発者の時間数などを説明することです。

GITがあなたの人生を楽にする、またはあなたの仲間の開発者の人生を楽にする理由を使ってアプローチしないでください。GITがソフトウェアをより速く、より安く出荷するという観点からアプローチしてください。

@ Buttons840のコードベースの[元に戻す]ボタンとしての説明が気に入っています。また、WordまたはInDesignの「変更の追跡」機能の（イライラの少ない）バージョンと比較すると役立つ場合があります。私の経験では、ある人が次の数時間ファイルX、Y、Zに触れないように他の人に言い回す必要性を確実に減らします。これは、物事を成し遂げるのに便利です。

また、詳細なバージョン情報は、バグの修正/回避に非常に役立つことがわかりました。生成するほぼすべてのデータファイルに（$ Idプロパティを介して）SVNバージョン番号を格納します。そうすれば、バグが（いつ？）見つかった場合、潜在的な問題のあるファイルを特定して再生成するか、他のコードでバグを補うのは簡単です。

バージョン管理を使用しない場合、運用環境を再構築する方法をどのように知っていますか？

1異なる人々（テスター、開発者）は異なる場所で同じ情報を探します

同期が取れなくなるDUPLICATE DATAにつながります。
バージョン管理は、重複データを排除する最も簡単な方法です。

2バージョン管理を使用している場合、本番環境がバージョン管理の内容と一致していることを簡単に確認できます。

これにより、問題の原因がビルドの不良（製品がバージョン管理と一致しない）か、設計またはコーディングのバグ（製品がバージョン管理と一致する）かを簡単に検出できます。

バージョン管理を使用すると、各テスト環境にリリース番号を簡単に割り当てることができます。当然、プロダクションはテストまたは開発よりもリリース番号が低く、テストは開発よりもリリース番号が低いと予想されます。そうでない場合は、コードの一部が適切にテストされていません。

また、ソフトウェアをリリースする場合、VCSの次の機能はかなり重要です。顧客がバグを見つけたと仮定します。ソフトウェアの現在の開発は、おそらく顧客が持っているバージョンとは非常に異なる状態です。バグは現在修正されているかもしれませんが、修正されていないかもしれませんが、いずれにせよ、現在のソフトウェアはお客様に出荷できる状態ではありません。

VCSを使用すると、顧客に出荷されたバージョンに戻り、要求していたバグを修正し、ビルドして、改訂バージョンを出荷することが簡単になります。これはすべて、現在の開発を妨げることなく、未完成/不安定な機能を備えたバージョンや、新しい未完成の開発のために追加されたバグを彼に出荷する必要はありません。

さらに、VCSでは、バグがまだ存在する場合、この修正を新しい開発ブランチに簡単に移植して戻すことができます。

強力な規律により、おそらく非常に小さなチームのためにVCSなしでこれを管理できますが、それを使用すると時間とお金を節約できます。ほとんどの場合、顧客を維持するのにも役立ちます。

会社に2人以上の人がいる場合は、複数の人が編集した単語文書またはExcel文書がどこかにある可能性があります。また、出張などのためにローカルコピーを作成する場合もあります。または、変更のたびにドキュメントがメールで送信されます。

そのようなファイルがある場合、一部の人々の変更は過去に失われたか、将来失われます。または、変更を失ったと思うが、それを証明することはできません。または、いつ誰が何を変更したのか、いつ、なぜ変更したいのかを確認したいのです。これがまさにVCSが解決する問題です。

オープンソースのソフトウェア/ライブラリを選択する場合、DVCSリポジトリを持つことは、選択基準で間違いなく利点です。

1）リポジトリ全体のクローンを作成できます。プロジェクトやそのWebサイトが停止していることを心配する必要はありません。

2）プルリクエストを介してバグ修正を送信する意思があるため、緊急の問題に対するバグ修正が迅速になります。