[解決済み] GIT vs. Perforce- 2つのVCSが参入し、1つは撤退する【クローズド】。

質問

そこで私は、職場でGITを売り込もうとしている最中です。まず最初に必要なのは、みんながすでに慣れていることで、GITの方が優れていることを納得させることです。現在、私たちはPerforceを使っています。誰か同じような売却を経験した人はいますか？何か良いリンクやアドバイスがあれば教えてください。

ネットワークから切り離して作業できるのが大きな勝因の一つです。もう一つの勝利は、追加/チェックアウトが処理される方法です。より多くのポイントを歓迎します! また、私たちは合計で10～20人ほどの開発者がいます。

解決方法は？

Perl 5 インタプリタのソースコードは、現在、Perforce から git への変換という苦難の道を歩んでいます。たぶん、Sam Vilainの git-p4raw インポーターは興味深いです。

いずれにせよ、あらゆる中央集権型VCSやほとんどの分散型VCSに対する大きな利点のひとつは、生の、まばゆいばかりの スピード . プロジェクトの全履歴がコンマ何秒の距離で手元にあるということが、どれほど開放的なことか、実際に体験してみないと想像できないだろう。各コミットの完全な差分を含むプロジェクト全体の履歴のコミットログを生成することさえ、コンマ数秒で測定することができます。Gitはとても速いので、帽子が飛ぶほどです。ネットワーク上でラウンドトリップしなければならないVCSは、ギガビット・イーサネット・リンクであっても、単純に対抗するチャンスがないのです。

また、git ではコミットする際に慎重に選択することができるので、作業コピーの変更（あるいはひとつのファイルの変更）を複数のコミットにわたって、必要であれば異なるブランチに分散して行うことができます。このため、作業中のメモを少なくすることができます。どのような変更をコミットするか前もって決めておき、それ以外は必ず後回しにするなど、注意深く作業計画を立てる必要がありません。思いついたときに好きなように変更し、コミットするときには、ほとんどいつも簡単にそれを解くことができます。 隠し場所 は、ここで非常に大きな助けとなります。

これらの事実を総合すると、gitを使う前よりも自然と多くの、より集中したコミットを行うようになることがわかりました。これは、一般的に履歴をより有用なものにするだけでなく、特に以下のような付加価値の高いツールに有益です。 git bisect .

今すぐには思いつかないものがもっとあると思います。gitでチームを売り込むという提案の問題点のひとつは、上でほのめかしたように、多くの利点が相互に関連し、互いに作用しあっていることです。そのため、gitの機能と利点のリストを見て、それらがあなたのワークフローをどう変えるのか、どの変更が確実な改善となるのかを推測するのは難しいことなのです。このことを考慮し、また、それを明確に指摘する必要があります。