GIT vs. Perforce-2つのVCSが入ります... 1つが出ます
だから、私は職場でGITを販売する過程にいます。私が最初に必要なことは、GITの方がすでに慣れていることに優れていることを全員に納得させることです。現在、Perforceを使用しています。他の誰かが同様の販売を経験しますか？良いリンク/アドバイスはありますか？
大きなメリットの1つは、ネットワークから切断された状態で作業できることです。 IMOのもう1つのメリットは、追加/チェックアウトの処理方法です。より多くのポイントを歓迎します！また、合計10〜20の開発者がいます。
Perl 5インタープリターのソースコードは現在、Perforceからgitに変換するという苦労を経験しています。たぶん、Sam Vilainのgit-p4rawインポーターは興味があります。
いずれにせよ、中央集中型のすべてのVCSで得られる主な勝利の1つであり、ほとんどの分散型VCSも生であり、猛烈なspeed。あなたがそれを経験するまで、プロジェクトの全履歴をほんの一瞬のほんの数分で手に入れることがどれほど自由であるか想像することはできません。各コミットの完全な差分を含むプロジェクト履歴全体のコミットログを生成することも、ほんの一瞬で測定できます。 Gitは非常に高速で、帽子が飛びます。ネットワーク上で往復する必要があるVCSは、ギガビットイーサネットリンク上でも競合する可能性がありません。
また、gitを使用すると、コミット時に慎重に選択することが非常に簡単になるため、作業コピー（または単一ファイル内）の変更を複数のコミットに（必要に応じて異なるブランチに）分散させることができます。これにより、作業中のメンタルノートを少なくすることができます。作業をそれほど慎重に計画する必要はなく、コミットする変更セットを事前に決定し、他の作業を延期する必要があります。必要に応じて変更を加えるだけで、コミットするときでも、ほとんど常に簡単に変更できます。 スタッシュ は、ここで非常に大きな助けになります。
これらの事実により、gitを使用する前よりも多くの集中的なコミットが自然に行われることがわかりました。これにより、一般的に履歴がより便利になるだけでなく、 git bisect などの付加価値ツールにとって特に有益です。
今は考えられないことがもっとあると思います。チームをgitで販売するという提案の1つの問題は、上記で示唆したように、多くのメリットが相互に関連しており、相互にやり取りしていることです。ワークフローを変更し、どの変更が真の改善となるでしょう。これを考慮する必要があり、明示的に指摘する必要もあります。
私は職場でPerforceを使用しています。 Gitを使用しているのは、コードの作業中にサーバーに接続できない場合でも、何らかの形式のバージョン管理が必要だからです。いいえ、オフライン作業の調整はまったく同じではありません。ここで、gitが大きな利点であることがわかりました。
- 分岐速度-gitは最大で数秒かかります。
- 競合-P4Mergeの自動解決により、1週間分の作業が一度破壊されました。それ以来、マージするときは手で解決したいと思います。 Gitが競合についてプロンプトを表示するとき、それは実際には競合です。残りの時間は、gitが問題を正しく解決し、時間を大幅に節約します。
- マージの追跡-1つのブランチが他の2つのブランチからマージを継続的に受信している場合、これがperforceでどのような頭痛の種になるかを知っています。 gitでは、gitのマージの結果は実際にはその祖先が誰であるかを知っている新しいコミットであるため、頭痛は最小限に抑えられます。
- 権限-ファイルを操作しようとした回数を追跡できませんでしたが、Perforceでチェックアウトされなかったためにできませんでした。 XCode（または堅実なPerforce SCMプラグインを持たない任意のエディター）をオフラインで使用した場合、これがどのように苛立たせるかがわかります。 Gitでそれについて心配する必要はありません。変更します。 Gitは私を止めず、バックグラウンドで追跡します。
- メインツリーを整頓する-gitを使用すると、コミットをソートし、コードを整頓して、履歴が整然と見えるようにすることができます。 「以前のチェックインの一部であるはずだったので、このファイルをチェックインする」ゴミはありません。彼らは誰にも役立たないので、私はそのようなコミットをつぶします。
- スタッシング-p4 shelveコマンドを使用するには、perforceサーバーがバージョン2010.1以降である必要があります。
- パッチの作成-gitで簡単に実行できます。コマンドラインを使用せずにPerforceでそれが可能かどうかわからない。
- GUIからパッチをメールで送信-再び、ここでgitが勝ちます。
- ディスク容量-perforceでは、すべてのブランチがコピーです。つまり、ソースツリーが巨大な場合、ディスク領域がすぐに消費されます。構築を開始すると、追加のスペースもカウントされません。ブランチとディスクスペースの間にリンクがあるのはなぜですか？ gitを使用すると、100のブランチを持つことができ、一度に1つのブランチしか存在しません。 2つのバージョンで同時に作業したい場合は、クローンを作成して作業を行い、必要に応じて1つのクローンを削除します。何も失うことはありません。
- XCode4を使用している場合、perforceサポートは廃止され、gitサポートが組み込まれています。私のようにクロスプラットフォームで作業する場合、これは非常に重要です。 Visual Studioでは、git拡張機能を使用できます。 PERFORCEを使用すると、両方のOSで同じようにうんざりします。まあ、もう少しMacでもう少しXCode4を使用してください。
- 欠陥のあるチェックイン（またはgit bisectルール）を見つける-バグが導入された場所を把握するために、perforceでバイナリ検索を試みたことがありますか？かなり面倒ですよね？途中で他のブランチから統合された場合、さらに面倒です。どうして？そのようなタスクの自動化がないためです。 PERFORCEと対話するには独自のツールを作成する必要があり、通常は時間がありません。 gitを使用すると、開始点（「良い」点と「悪い」点）を指定して、検索を自動化します。さらに良いことに、ビルドとテストのプロセスを自動化できるスクリプトがある場合、gitをスクリプトに接続することができ、チェックインを見つけるプロセス全体が自動化されます。それはそうあるべきです。
- リファクタリング全体の変更の追跡-BigClassをSmallClass1とSmallClass2に分割してみてください。 Perforceにとって、BigClassは存在しなくなり、2つの新しいクラス（SmallClass1とSmallClass2がソースツリーに加わりました）。 Perforceにとって、BigClassとSmallClass1およびSmallClass2の間には関係がありません。一方、Gitは、BigClassのx％が現在SmallClass1にあり、BigClassのy％がSmallClass2にあり、BigClassが存在しなくなったことを知るのに十分賢いです。さて、複数のブランチにわたる変更をレビューしている誰かの観点から、GitとPerforceのどちらがより便利だと思うかを教えてください。個人的には、コードの実際の変更をより正確に反映するため、Gitのアプローチを好みます。 Gitは、ファイル自体ではなくファイル内のコンテンツを追跡するため、これを行うことができます。
- 集中型または分散型：Gitは [〜＃〜] dvcs [〜＃〜] システムであり、perforceは集中型です。集中型VCSは後で分散化できませんが、DVCS（特にgit）は集中化できます。ビジネスで必要な場合は、Gitに非常にきめの細かいアクセス制御を追加する製品がいくつかあります。個人的には、長期的に柔軟性を高めるシステムを使用します。
- ブランチマッピング：Perforceで直接ブランチを実行する場合は、ブランチマッピングを作成する必要があります。これには理由がありますが、Perforceがブランチを概念化する方法に関係しています。開発者、またはチームとして、これは単にワークフローのもう1つのステップを意味しますが、これはまったく効率的ではないと思います。
- チーム間で作業を共有する：Perforceでは、提出物を分割することはできません。チームAは機能Aに取り組んでいます。チームBは機能Bに取り組んでいます。チームCはバグ修正に取り組んでいます。現在、チームAとBは、機能を実装するために多数のバグを修正する必要があります。唯一のことは、変更をコミットするときに規律が厳しくなかったためです（おそらく、締め切りに間に合っているためです）。そのため、「バグ修正」は、バージョン管理に関する限り、枝が心配です。ただし、チームCは現在ポイントリリースを行っており、他のチームからバグ修正を入手したいと考えています。 Gitを使用している場合、チームCは他のチームの関連する変更を選択し、それらを分割し、部分的に実装された機能を導入することを心配せずに必要なものだけを使用できます。 Perforceを使用すると、チームCは影響を受けるファイルを取得できますが、より多くの手動プロセスを使用して関連する変更を分離する必要があります。
- プラットフォームの変更-将来何らかの理由でPerforceを使用して選択したプラットフォームを変更することにした場合、Perforce.comと選択したプラットフォームのツールが利用できるようになります。
- 将来の驚くべきソース管理エンジンXへの変更-ソース管理に使用するものを変更することにした場合、Perforceからソース管理履歴を抽出して新しいシステムXに移動するのは悪夢になります。あなたができることは推測です-私が話していることの感覚を得るために、Google for PerforceからGitへの移行だけです。少なくともそのオープンソースであるGitを使用すると、多くの推測作業が不要になります。
まあ、それは私の2セントです。 PERFORCEの弁護では、カスタマーサポートルールと、タイムラプスビューツールも同様だと言わざるを得ません。 gitでタイムラプスビューを取得する方法がわかりません。しかし、利便性と時間の節約のために、私はいつでもgitを使います。
Perforceから切り替えるには説得力があります。私が使用した2つの会社では、それは十分すぎるほどでした。それらは両方とも異なるオフィスを持つ企業でしたが、オフィスには十分なインフラストラクチャがセットアップされていたため、切り離された/切断された機能を持つ必要はありませんでした。
何人の開発者が交代について話しているのですか？
本当の質問は-gitが提供できる組織のニーズを満たしていないperforceについてはどうですか？同様に、gitはperforceと比較してどのような弱点がありますか？自分で答えられない場合は、ここで質問しても役に立ちません。会社のビジネスケースを見つける必要があります。 （例：おそらく、全体的な所有コストが低くなります（中間学習段階での生産性の低下、（少なくとも最初の）管理コストの増加などを含む）
私はあなたが厳しい売りに出ていると思います-PERFORCEは交換しようとするのにかなり良いものです。あなたがPVCまたは安全を起動しようとしている場合、それは簡単です。
切り替え中/切り替え後の人々を幸せに保つという観点から、早期に理解するべきことの1つは、ローカルブランチがGitでどれだけプライベートになり、ミスを犯すことができるかということです。それらすべてを取得して、現在のコードからいくつかのプライベートブランチをクローンし、そこで実験を行います。いくつかのファイルの名前を変更し、チェックインし、別のブランチからのものをマージし、履歴を巻き戻し、変更セットを別のセットの上にリベースします。彼らの最悪の事故でさえ、同僚にどう影響しないかを示してください。あなたが望むのは、開発者が安全だと感じ、より速く学ぶことができる状況であり（Gitには重要な学習曲線があるため）、最終的には開発者としてより効果的になります。
一元化されたツールを学ぼうとしているとき、明らかに、リポジトリの他のユーザーに問題を引き起こすいくつかの愚かさを心配するでしょう。恥ずかしさだけの恐怖は、人々が実験するのを思いとどまらせるのに十分です。特別な「トレーニング」リポジトリを用意しても、開発者はトレーニング中に見たことのない本番システムの状況に遭遇することは避けられず、心配に戻ってしまいます。
しかし、Gitの分散された性質はこれを排除します。ローカルブランチで実験を試すことができます。もしそれがひどく間違っている場合は、ブランチを捨ててください。だれも知る必要はありません。何でもローカルブランチを作成できるので、実際のライブリポジトリで見ている問題を再現できますが、「ビルドを壊す」などの危険はありません。完了したらすぐにすべてをチェックインすることができ、バッチ処理してきれいな小さなパッケージにしようとすることはありません。そのため、今日4時間を費やした2つの主要なコード変更だけでなく、途中で覚えていたビルドの修正、同僚に何かを説明するときに見つけたドキュメントのスペルミスなども修正されました。また、プロジェクトの方向が変わっているために主要な変更が放棄された場合は、ブランチからビルド修正とスペルミスを選択し、それらを簡単に維持できます。
人々が使用しているPerforce機能は何ですか？
- 単一のマシン上の複数のワークスペース
- 番号付きチェンジリスト
- 開発者ブランチ
- IDE（Visual Studio、Eclipse、SlickEdit、...）との統合
- 多くのビルドバリアント
- 複合ワークスペース
- いくつかの修正を統合するが、他の修正は統合しない
- 等
すべての人がコマンドラインから取得して取得するのであれば、gitがそれをカバーしているので、他のすべてのRTSも同様です。
個人的にgitで私を売ったコマンドは bisect でした。現在のところ、この機能が他のバージョン管理システムで利用できるとは思いません。
そうは言っても、ソース管理のためにGUIクライアントに慣れている人は、gitに感心することはないでしょう。現在、フル機能のクライアントはコマンドラインのみです。
どうやら GitHubはgitトレーニングコースを企業に提供するようになりました 。 Quoth それについての彼らのブログ投稿 ：
私はここ数週間、GitでAndroidのトレーニングを支援するために何度もGoogleキャンパスに行ってきました。ショーン・ピアース（彼のGitとEGit/JGitの栄光から彼を知っているかもしれません-彼はJunioが町を離れたときに保守を引き継ぐヒーローです）に、Andriodで働いているGoogleエンジニアのトレーニングを支援するように頼まれました perforceからGitへの移行、だからAndroidを大衆と共有することができた。私はそれをやったこと以上に幸せだったと言える。
[…]
Logical Awesomeが 正式に提供 すべての企業にこのタイプのカスタムトレーニングサービスを提供します。Gitへの切り替えを検討している場合は、トレーニングとプランニングで組織を支援できます。
強調鉱山。
しばらくGitを使用していましたが、最近Gitサーバーのハードドライブがクラッシュし、最新の状態に戻すことができませんでした。数日前の状態に戻ることができました。サーバーがバックアップされたとき。チームの全員が変更をプル/プッシュしました。サーバーは現在の状態に戻りました。
私は長い間Perforceを使用していますが、最近GITも使用し始めました。これが私の「客観的」意見です。
PERFORCEの機能：
- GUIツールは機能が豊富になっているようです（タイムラプスビュー、リビジョングラフなど）
- 最新リビジョンに同期するときの速度（履歴全体を転送するオーバーヘッドなし）
- Eclipse/Visual Studioの統合は本当に素晴らしい
- チェンジリストごとに1つのブランチで複数の機能を開発できます（これがGITよりも優れているかどうかはまだ100％確信できません）
- 他の開発者が何をしているかを「スパイ」することができます-彼らがチェックアウトしたファイルの種類。
GIT機能：
- GITコマンドラインはPerforce（init/clone、add、commit。複雑なワークスペースの構成はありません）よりもはるかに簡単だという印象を受けました。
- チェックアウト後にプロジェクト履歴にアクセスするときの速度（同期時に履歴全体をコピーするコストがかかります）
- オフラインモード（開発者は、到達不能なP4サーバーがコーディングを禁止することを訴えません）
- 新しいブランチの作成ははるかに高速です
- 「メイン」GITサーバーは、各開発者が独自のローカルサンドボックスを持つことができるため、十分なTBytesのストレージを必要としません。
- GITはオープンソース-ライセンス料なし
- あなたの会社がOpenSourceプロジェクトにも貢献している場合、パッチの共有はGITではるかに簡単です
全体的にOpenSource/Distributedプロジェクトの場合、GITはP2Pアプリケーションに似ており、誰でも開発に参加できるため、常にGITをお勧めします。たとえば、Perforceでリモート開発を行っていたとき、1週間に1回、1 Mbpsリンクで4 GBプロジェクトを同期していたことを思い出します。そのため、多くの時間が無駄になっただけです。また、そのためにVPNをセットアップする必要がありました。
小規模な会社があり、P4サーバーが常に稼働している場合、Perforceも非常に優れたオプションであると言えます。
GITが勝つことを知っていることの1つは、すべてのファイルの「行末を保持する」能力ですが、perforceはそれらをUnix、Dos/WindowsまたはMacOS9形式（「\ n」、「\ r\n "または"\r）。
Windows環境または混合OS環境でUnixスクリプトを記述している場合、これは非常に苦痛です。ファイル拡張子ごとにルールを設定することもできません。たとえば、.sh、.bash、.unixファイルをUnix形式に変換し、.ccp、.bat、または.comファイルをDos/Windows形式に変換します。
GIT（これがデフォルト、オプション、または唯一のオプションかどうかはわかりません）では、「行末を保持する」ように設定できます。つまり、ファイルの行末を手動で変更すると、GITはその形式をそのままにします。これは物事を行うための理想的な方法のように思えますが、なぜこれがPerforceのオプションではないのか理解できません。
この動作を実現できる唯一の方法は、ファイルをバイナリとしてマークすることです。私が見るように、それは欠落している機能を回避するための厄介なハックになるでしょう。すべてのスクリプトなどで行うのは面倒ですが、おそらくほとんどの差分なども壊れます。
現時点で解決した「解決策」は、sedコマンドを実行して、スクリプトがUnix環境に展開されるたびにスクリプトからすべてのキャリッジリターンを削除することです。これも理想的ではありません。特に、それらのいくつかはWARファイル内にデプロイされており、展開したときにsed行を再度実行する必要があります。
これは、GITに大きな利点をもたらすと思うものであり、上記で言及したことはないと思います。
編集：PERFORCEをもう少し使用していた後、コメントをいくつか追加したいと思います。
A）Perforceで本当に見落としているのは、変更されたファイル、削除されたファイル、追加されたファイルなど、明確でインスタンスの差分です。これはGITでgit diffコマンドを使用して利用できますが、Perforceでは、変更を記録する前にファイルをチェックアウトする必要があります。また、Eclipseなどのメインエディターでそれらを編集すると、他の方法（メモ帳、unixコマンドなど）でファイルを編集する場合があります。また、Eclipseやp4Eclipseを使用しても、新しいファイルが自動的に追加されることはないようです。したがって、すべての変更を見つけるには、ワークスペース全体で「に対して...」を実行する必要があります。まず、実行に時間がかかり、次に非常に複雑な除外リストを設定しない限り、あらゆる種類の無関係なものが含まれます。次のポイントに私を導きます。
B）GITでは、.gitignoreは非常にシンプルで管理しやすく、読みやすく、理解しやすいと感じています。ただし、Perforceで設定可能なワークスペースの無視/除外リストは扱いにくく、不必要に複雑に見えます。ワイルドカードが機能する除外を取得できませんでした。私は次のようなことをしたいです
-//Server/mainline/.../target/... //Svend_Hansen_Server/.../target/...
サーバー/メインライン内のすべてのプロジェクト内のすべてのターゲットフォルダーを除外します。しかし、これは期待したとおりに機能しないようで、すべてのプロジェクトに次のような行を追加しました。
-//Server/mainline/projectA/target/... //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/... //Svend_Hansen_Server/projectB/target/...
...
Binフォルダー、.classpathおよび.projetファイルなどの同様の行。
C）Perforceには、かなり便利なチェンジリストがあります。ただし、変更のグループを作成し、それらすべてをチェックしてチェンジリストに入れ、そのチェンジリストを送信する前に他の作業を行うと仮定します。後で最初のチェンジリストに含まれるファイルの1つに変更を加えた場合、そのファイルはそのチェンジリストに残り、最初に追加した変更のみが含まれていると仮定して、後でチェンジリストを送信することはできません（ただし、同じファイルになります）。 GITでは、ファイルを追加してさらに変更を加えた場合、それらの変更は追加されず（git diffに表示され、最初にファイルを追加しないとファイルをコミットできません）もちろん、これは変更リストが1セットの追加ファイルしかないのと同じように便利ではありませんが、GITでは実際にプッシュしないので、変更をコミットすることができます。それらをプッシュする前に他の変更を処理することはできますが、前に加えた変更をプッシュせずに、後で追加するものをプッシュすることはできません。
Perforceとgit（および最も一般的に言及されているもの）の1つの重要な違いは、それぞれの巨大なバイナリファイルの処理です。
たとえば、このビデオゲーム開発会社の従業員のブログのように： http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html
しかし、重要なことは、ドキュメントとこれまでに構築されたすべてのバイナリ（そして最後に、はい！実際のソース履歴）のすべてを含む巨大な6gbリポジトリがある場合、gitとperforceの速度の違いは通常、巨大企業はPerforceを実行する傾向があるため、すべての重要な操作を地下の巨大サーバーバンクにオフロードするように設定しています。
PERFORCEのこの重要な利点は、PERFORCEとは何の関係もない要因、つまり、PERFORCEを実行している会社が上記のサーバーバンクに余裕があるという事実に起因しています。
とにかく、結局のところ、Perforceとgitは異なる製品です。 GitはVCSのみとして設計されており、これはPerforceよりもはるかに優れています（より多くの機能があり、特に別の言い方をすれば、Perforceでのブランチはオープンハートを実行するようなものです）手術、専門家のみが行うべきです：P）（ http://stevehanov.ca/blog/index.php?id=5 ）
PERFORCEを使用する企業が享受するその他の利点は、PERFORCEがVCSだけでなく、ファイルサーバーでもあり、ビルドのパフォーマンスをテストするためのその他の機能のホストを持っていることだけが理由です。
最後に：Gitはオープンソースであり、ブートがはるかに柔軟であるため、高価なハードウェアを実行する中央サーバーに重要な操作をオフロードするためにgitにパッチを当てることはそれほど難しくありません。
Gitの経験はありませんが、分散VCSでもあるMercurialの経験はあります。本当にプロジェクトに依存しますが、私たちの場合、分散VCSは頻繁に壊れたビルドを基本的に排除するため、プロジェクトに適していました。
クライアントサーバーVCSに向いているものもあれば、分散VCSに向いているものもあるため、プロジェクトに本当に依存していると思います。