上司は新しいプロジェクトにバージョン管理システムを使用することに懐疑的ですが、とにかく私はどうでしょうか？

/software/109817/superior-refusing-to-use-subversionを参照してください

私の質問も同様ですが、私のシナリオの主な違いは次のとおりです。

• PHPとウェブ技術を使用して、新しいプロジェクトをゼロから始めています。私のやり方があれば、最初から採用するので、開発にダウンタイムはありません。

• 私の開発チームは私と私の上司で構成されています。私たちは比較的小さな会社の「IT」部門です。

Webアプリは、ソース管理がまったくないレガシーアプリケーションを置き換えます。地理的な法的要件の違いにより、（私が採用される前に）アプリをバージョンごとに7つの完全に別個のディレクトリにフォークすることが決定されました。その後、さまざまな開発者がさまざまな場所でさまざまなことを行いました。それら全体にパッチを当てるということは、まあ、もっとうまくできると思います。それが私が投稿している理由だと思います。

メールから直接貼り付けた上司の提案：

• 更新はSUBMISSIONSフォルダーにパッケージとして送信する必要があります。パッケージには、関連するすべてのファイルと、更新の説明、含まれているすべての新しいファイルのリスト（説明付き）、および変更の詳細を含むすべての変更されたファイルのリストを含む「UPDATE.NFO」ファイルが含まれている必要があります。

• 更新パッケージは、個々の要素に焦点を当て、意図された目的から逸脱しないようにする必要があります。コードはモジュール化され、可能な限り再利用できるように設計する必要があります。

• 提出されたすべてのパッケージは、提出後すぐに各開発者のテスト環境にインストールする必要があります。各開発者は、新しい追加を確認し、本番環境へのインストールに関する懸念を表明します。標準のパッケージアップデートは、本番環境にロードされる前に、このレビュープロセスのために最低3営業日保持される必要があります。優先度の高い更新/修正では、この要件をスキップできます。

ソース管理が発明された理由は、それをすべて自動化するためですよね？それが私が大学で使用したものだから、私は転覆を提案しました。「コードがめちゃくちゃになる」（つまり、バイナリマジックを使用しており、明確に読み取ることができない）ため、ボスはSubversionを好みません。一度試してみましたが、Windowsで使用しようとすると、奇妙な小文字/大文字のエラーが発生し、ファイルをチェックアウトできませんでした。それがsubversionだけなのか、それとも不快なすべてのソース管理製品なのかはわかりません。

では、上司に対してどのような議論をするべきでしょうか。それとも彼は正しいのですか、そして奇妙なバグから私たちのすべての仕事を失う危険があるかもしれませんか？

または私は完全に間違っていますか？私の状況ではソース管理が本当に必要ですか？これは私たちが話している主要なビジネスクリティカルなソフトウェアなので、間違いなく巨大になるでしょう。しかし、開発者は2人だけです（現在）。

さらに、彼を納得させることができない場合、私だけにそれを使用することに意味がありますか？私は実際にsvnを使用した非常に限られた経験を持つ誰かとして話しています。私が本当に知っているのは、チェックアウトとコミットだけです。個人の開発作業に役立つソース管理の機能（svn以外の製品が含まれる場合があります）は何ですか？

「別の仕事を取得する」コメントはありません。それは議論に役立たない。

彼に尋ねないでください。彼に言わないでください。彼に見せてください。

svn、git、または好きなものを追加のマシンにインストールします。使用するだけでなく説明するまで、自分で使用する練習をしてください。あなたが彼にあなたの新しいシステムを快適にさせるつもりなら、あなた自身でそれ以上に快適である必要があるでしょう。彼がマージを台無しにしたり、何かを間違った場所にチェックインしたりしたときに、彼が簡単に回復できるように手助けできる必要があります。

準備ができたら、あなたが話していることを正確に彼に示してください。それが何も「台無しにしない」ことを彼に示しなさい。コードの以前のバージョンを簡単に取得できるだけでなく、2つのバージョン間で何が変更されたかを正確に知ることもできます。

サーバーに何かが起こった場合（深刻なバグ、ウイルス、ハッカー、ディスククラッシュなど）、必要なバージョンをすぐに再構築できれば、両方ともヒーローのように見えることを指摘します。また、オンデマンドで任意のバージョンを作成できる場合は、外観が2倍になることも指摘してください。古い電子メールを検索し、バージョン管理で回避できた、過去1年間に発生した問題のリストをまとめます。

彼があなたのバージョン管理システムを使いやすくするためのチートシートを彼に与えてください。

最後に、いくつかのオプションを提案しますが、決定は彼に任せます。独自のサーバーをセットアップするか、多数のホスティングサービスの 1つを使用する必要がありますか？svn、git、または他のものを使用する必要がありますか？7つのプロジェクトすべてをシステムに移行する必要がありますか、それとも最初に1つまたは2つのプロジェクトを試してみますか？

ソース管理の利点は、複数の開発者が単一のコードで作業できるようにするだけではありません。SourceGearの創設者であるEric Sinkは、ソース管理を単一の開発者として使用する説得力のある理由をいくつか挙げています。

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

エリックはまた、非常に優れた初心者向けのソース管理ハウツーを持っています。Joel Spolskyが提供する無料のオンラインMercurialチュートリアルがあり、Mercurialは人気のある分散バージョン管理システムです。

次のステップとして、単一の開発者として、マシン上でローカルにソース管理を使用することをお勧めします。すぐに上司は、数秒ではなくても数分以内に、超重大なバグがどこまで遡ったかを伝え、影響を受けた顧客アカウントを正確に伝え、何よりも先に修正が必要であることに気づくことができます。地獄は緩んで壊れます。または、CEOが非常に速く不承認にした変更を元に戻すことができる。

そして最後に、上司を説得しようとする前に、異論への切り返しのトピックについて掘り下げたいと思うかもしれません。売り上げ101本です。

失敗した場合-できるだけ早く、風車で傾いている時間を無駄にしても意味がありません。

はい、ソース管理を使用することは、たとえあなたにとってだけでも、完全に価値があります。たとえば、Gitはスタンドアロンの開発者にとって非常にうまく機能し、ブランチやマージ（最小限のコストで）を実行したり、変更をバージョン管理したりすることができます。

SVN-または任意のバージョン管理システムでは、実際にこれを行うこともできますが、マージは少し問題があります。

私が彼を納得させることができないなら、私だけのためにそれを使用する私に何か意味があるでしょうか？

はい。自分だけで使用することにはメリットがあります。変更履歴を取得して、何が違うのかを確認できます。

いいえ。上司がプロジェクトを壊滅させ、多くの無意味なやり直しを行ったため、利益がありません。

前述のようにgitを使用することを強くお勧めします。理由＃1は、どのVCSも災害時のセーフティネットであるためです。「火災の場合：git commit、git push、建物から離れる」ステッカーを探します。コードは別の場所に保存されている可能性がありますが、故障したり盗難に遭ったりするラップトップには保存できません...ローカルネットワークサーバーでさえ、コードと同じくらい価値のあるものにとって最も安全な場所ではありません。

番号2.変更のトレーサビリティ、誰が何をしたか、いつなど...マージ、元に戻す。番号3。＃2およびその他のケースで魔法のツールを比較します。番号4。ブランチ番号5。バージョン、リリースなどのタグ付け。

最も一般的なgitワークフローの詳細については、https：//nvie.com/posts/a-successful-git-branching-model/をご覧ください。

gitを使用することは最初は気が遠くなることを知っていますが、それはスキルにとっては良い投資であり、開発チームにとっては必需品です。

テキストケースの問題については、Tortoiseの使用は避けてください。SVNでは非常に一般的だったため、GitのGUIとしてほとんどの人がそれを使用しているので、コマンドラインまたはgithubデスクトップのような別のGUIを使用することをお勧めします。またはアトラシアンのSourceTree。