これまで、開発チームは Lock ベースの SCM (Source Control Management) システムを使用してきました。最近、システムを新しい、より良いものに置き換える必要に迫られています。
新しいシステムとして、Git を使用することを提案しました。私を含む数人のメンバーを除いて、彼らは Git について聞いたことがありません。だから私はそれについていくつかの説明をしました。
問題は、ソース コードの整合性を維持する上で、ロック システムよりもマージ システムの方が安全ではないと彼らが考えていることです。
Git のシステムや、すでに Git システムを使用している多くの有名なプロジェクトとその素晴らしい評判について説明しても、彼らは Git に安心することはありませんでした。
どうすれば彼らを安心させることができるでしょうか。マージが問題ではないことをどのように説明できますか?
マージ ベースのシステム自体は、ロック ベースのシステムより優れているわけではありません。それはすべてあなたのプロジェクトに依存します。マージできないファイルがある場合は、ロックベースのシステムの方がおそらく優れています。
しかし、私があなたの質問を正しく理解しているなら、あなたは同僚を説得する方法を知りたがっています.
Linux が良い例であり、Linux の開発はロックベースのシステムでは決して不可能だったと主張することができます。ただし、Linux には巨大な開発ベースがありますが、おそらくあなたのチームにはありません。したがって、それは実際には議論ではありません。問題がなければ、スケーラビリティとマルチ ユーザーから得られるすべての利点は当てはまりません。
ただし、同僚はコードの整合性について心配しています。だからこそ、システムを変更する必要があります。ロックベースのアプローチはファイル中心です。(もちろん、svn のようなこの問題に対する中間の解決策がありますが、cvs och vss のようなものを使用するとしましょう)。ただし、1 つのファイルが単独で配布されることはめったにありません。
つまり、1 つのファイルの変更は、相互に通信するため、他のファイルに影響を与えます。ロックベースのアプローチを使用すると、自分の変更が他の同僚の変更にどのように影響するかはわかりません。ファイル A をリビジョン 2 に更新し、ファイル B をリビジョン 1 でテストしてから、同僚がファイル B をリビジョン 2 に更新した場合、それが機能することをどのように確認できますか? なぜあなたの同僚は、それが問題になる可能性があると考えるでしょうか? 彼はファイル B だけに触れたのに、なぜファイル A をテストするのでしょうか?
git を使用すると、システム ベースのアプローチで問題に対処できます。各変更はリポジトリ全体に対する変更であり、常に動作が保証されたバージョンを使用できます。重要なのは、とにかくコードの整合性を台無しにするファイルだけを見ることです。