85

だから私は仕事でGITを売ろうとしているところです。私が最初に必要とすることは、GIT が既に慣れ親しんでいることで優れていることを全員に納得させることです。現在、Perforce を使用しています。似たようなセールを行っている人はいますか？良いリンク/アドバイスはありますか?

大きな利点の 1 つは、ネットワークから切断された状態で作業できることです。もう 1 つの勝利 IMO は、追加/チェックアウトの処理方法です。さらにポイント大歓迎！また、合計で約 10 ～ 20 人の開発者がいます。

4

14 に答える 14

84

仕事でPERFORCEを使っています。また、コードの作業中にサーバーに接続できない場合でも、なんらかのバージョン管理が必要なため、Git を使用しています。いいえ、オフライン作業の調整は同じではありません。git が大きな利点であることがわかったのは、次の場合です。

  1. 分岐速度 - git はせいぜい数秒しかかかりません。
  2. 競合 - P4Merge の自動解決により、1 週間分の作業が 1 回破棄されました。それ以来、マージするときは手で解決したいと思っています。Git がコンフリクトについてプロンプトを出すとき、それは実際にはコンフリクトです。残りの時間は、git が問題を正しく解決してくれるので、かなりの時間を節約できます。
  3. マージの追跡 - 1 つのブランチが他の 2 つのブランチから継続的にマージを受信して​​いる場合、これが perforce でどのような頭痛の種になるかを知っています。git を使用すると、git でのマージの結果は、実際にはその祖先が誰であるかを知っている新しいコミットになるため、頭痛は最小限に抑えられます。
  4. パーミッション - ファイルを操作しようとしたが、Perforce でチェックアウトされていなかったために実行できなかった回数がわかりません。XCode (またはしっかりした Perforce SCM プラグインを持たないエディタ) をオフラインで使用したことがある場合は、これがどれほど苛立たしいものになるかがわかります。Git ではその心配はありません。私は自分の変更を行います。Git は私を止めず、バックグラウンドでそれらを追跡します。
  5. メイン ツリーを整頓する - git を使用すると、コミットを整理してコードを整頓し、履歴がきれいに整頓されるようにできます。「以前のチェックインの一部であるはずだったので、このファイルをチェックインする」というゴミはありません。誰の役にも立たないので、私はそのようなコミットをつぶします。
  6. スタッシング - p4 shelve コマンドを使用するには、perforce サーバーがバージョン 2010.1 以降である必要があります。
  7. パッチの作成 - git で簡単に作成できます。コマンドラインを使用せずにPerforceで可能かどうかはわかりません。
  8. GUI からのパッチの郵送 - ここでも git が勝ちます。
  9. ディスク容量 - perforce を使用すると、すべてのブランチがコピーになります。つまり、ソース ツリーが巨大な場合、ディスク スペースがすぐに使い果たされます。これは、構築を開始した後の追加スペースもカウントしていません。ブランチとディスク容量の間にリンクがあるのはなぜですか? git では、100 個のブランチを持つことができますが、一度に存在するブランチは 1 つだけです。特に 2 つのバージョンで同時に作業したい場合は、クローンを作成し、作業を行ってから、必要に応じて 1 つのクローンを取り除くことができます。何も失うことはありません。
  10. XCode4 を使用している場合、perforce のサポートは削除され、git のサポートが組み込まれました。私のようにクロス プラットフォームの作業を行う場合、これは非常に重要です。Visual Studio では、git 拡張機能を使用できます。perforce を使用すると、両方の OS で同じようにうまくいきません。まあ、XCode4 がシーンに登場した今、Mac ではもう少しかもしれません。
  11. 欠陥のあるチェックイン (または git bisect ルール) を見つける - perforce でバイナリ検索を実行して、バグが導入された場所を見つけようとしたことがありますか? かなり面倒ですよね？途中で他のブランチからの統合があった場合は、さらに面倒です。なんで？そのようなタスクの自動化がないためです。perforce と対話するための独自のツールを作成する必要がありますが、通常は時間がありません。git では、開始点 (「良い」点と「悪い」点) を指定すると、検索が自動化されます。さらに良いことに、ビルドとテストのプロセスを自動化できるスクリプトがある場合は、スクリプトに git を接続すると、チェックインを見つけるプロセス全体が自動化されます。そうあるべきです。
  12. リファクタ間の変更の追跡 - BigClass を SmallClass1 と SmallClass2 に分割してみてください。Perforce にとって、BigClass は存在しなくなり、2 つの新しいクラス (SmallClass1 と SmallClass2 がソース ツリーに加わりました)。Perforce にとって、BigClass と SmallClass1 および SmallClass2 の間には関係がありません。一方、Git は、BigClass の x% が現在 SmallClass1 にあり、BigClass の y% が SmallClass2 にあり、BigClass が存在しなくなったことを十分に認識できます。ここで、複数のブランチにまたがる変更をレビューしている人の観点から、Git と Perforce のどちらのアプローチがより役立つと思うか教えてください。個人的には、コードの実際の変更をより正確に反映する Git のアプローチを好みます。Git は、ファイル自体ではなくファイル内のコンテンツを追跡するため、これを行うことができます。
  13. 集中型または分散型: Git はDVCSシステムですが、perforce は集中型です。集中化された VCS は後で分散化できませんが、DVCS (特に git) は集中化できます。ビジネスで必要な場合は、非常にきめ細かいアクセス制御を git に追加する製品がいくつかあります。個人的には、長期的に柔軟性が高いシステムを採用したいと考えています。
  14. ブランチ マッピング: Perforce で直接ブランチを作成する場合は、ブランチ マッピングを作成する必要があります。これには理由がありますが、Perforce がブランチをどのように概念化するかに関係しています。開発者またはチームとして、これは単純にワークフローのステップが 1 つ増えることを意味しますが、これはまったく効率的ではないと考えています。
  15. チーム間で作業を共有する: Perforce では、提出物を分割することはできません。チーム A は機能 A に取り組んでいます。チーム B は機能 B に取り組んでいます。チーム C はバグ修正に取り組んでいます。現在、チーム A とチーム B は、機能を実装するために多数のバグを修正する必要があります。唯一のことは、彼らは変更をコミットするときにそれほど規律がなかったことです (おそらく締め切りに急いでいるためです)。そのため、彼らの「バグ修正」は、バージョン管理に関する限り新しいものも含む大きな提出物の一部です。枝が気になります。ただし、チーム C は現在ポイント リリースを行っており、他のチームからバグ修正を入手したいと考えています。チーム C が Git を使用している場合、チーム C は、他のチームの関連する変更を厳選して分割し、部分的に実装された機能を導入することを心配することなく、必要なものだけを採用することができます。パーフォースでは、
  16. プラットフォームの変更 - 将来、何らかの理由で選択したプラットフォームを変更することを決定した場合、Perforce では、Perforce.com と、選択したプラットフォーム用のツールの可用性に左右されます。
  17. 将来の素晴らしいソース管理エンジン X への変更 - ソース管理に使用するものを変更する場合、Perforce からソース管理履歴を抽出して新しいシステム X に移動するのは悪夢になるでしょう。あなたができることは推測です-私が話していることを理解するためにPerforceからGitへの移行のためのGoogleだけです。少なくとも Git はオープン ソースであるため、当て推量の多くが不要になります。

ええと、それは私の 2 セントです。Perforce の弁護において、私は彼らの顧客サポート規則を言わなければなりません。また、彼らの Time Lapse View ツールもそうです。gitでタイムラプスビューを取得する方法がわかりません。しかし、利便性と時間を節約するために、私はいつでも git を使用します。

于 2010-05-06T03:54:25.993 に答える
75

Perl 5インタープリターのソースコードは現在、PERFORCEからgitへの変換の苦境を乗り越えています。たぶんSamVilainのgit-p4raw輸入業者が興味を持っています。

いずれにせよ、すべての集中型VCSに勝る大きな勝利のひとつであり、ほとんどの分散型の勝利も生の、猛烈なスピードです。あなたがそれを経験するまで、プロジェクトの歴史全体を手元に置いておくことがどれほど自由であるかを想像することはできません。各コミットの完全な差分を含むプロジェクト履歴全体のコミットログを生成することでさえ、1秒未満で測定できます。Gitはとても速いので、帽子が飛び散ります。ネットワークを介してラウンドトリップする必要があるVCSは、ギガビットイーサネットリンクを介しても競合する可能性がありません。

また、gitを使用すると、コミットを行うときに慎重に選択することが非常に簡単になります。これにより、作業コピーの変更（または単一のファイル内でも）を複数のコミットに分散でき、必要に応じてさまざまなブランチに分散できます。これにより、作業中のメンタルノートを減らすことができます。作業を慎重に計画する必要はなく、コミットする変更のセットを事前に決定し、他の変更は必ず延期します。必要に応じて変更を加えることができますが、コミットするときは、ほとんどの場合、非常に簡単に変更を解くことができます。隠し場所はここで非常に大きな助けになります。

これらの事実が合わさって、gitを使用する前よりもはるかに多くの焦点を絞ったコミットを自然に行うことができます。これにより、履歴が一般的に役立つだけでなく、などの付加価値ツールにとって特に有益になりますgit bisect。

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

于 2008-10-21T23:41:43.477 に答える
46

perforce から切り替えるには、かなりの説得力が必要です。私が使用した2つの会社では、十分すぎるほどでした。どちらも異なるオフィスを持つ企業でしたが、オフィスには十分なインフラストラクチャが用意されていたため、バラバラ/バラバラの機能を持つ必要はありませんでした。

何人の開発者が変更について話しているのですか?

本当の質問は、git が提供できる組織のニーズを満たしていない perforce の原因は何ですか? 同様に、perforce と比較して git にはどのような弱点がありますか? 自分で答えられないなら、ここで質問しても意味がありません。あなたの会社のビジネスケースを見つける必要があります。(例えば、全体的な所有コストが低い (中間学習段階での生産性の損失、(少なくとも最初の) 管理コストの増加などを含む) など)。

あなたは厳しい売り込みをしていると思います-perforceは置き換えを試みるのにかなり良いものです. PVC や ssafe を起動しようとしている場合は、簡単です。

于 2008-10-21T18:19:53.593 に答える
15

切り替え中/切り替え後に人々を満足させ続けるという点で、早い段階で理解しておくべきことの 1 つは、ローカル ブランチが Git でどれだけ非公開にできるか、そしてどれだけ自由に間違いを犯すことができるかということだと思います。全員に現在のコードからいくつかのプライベート ブランチのクローンを作成してもらい、そこで実験を行います。一部のファイルの名前を変更したり、チェックインしたり、別のブランチからのものをマージしたり、履歴を巻き戻したり、ある変更セットを別の変更の上にリベースしたりします。ローカルで最悪の事故が発生しても、同僚には何の影響もないことを示します。あなたが望むのは、開発者が安全だと感じ、より速く学習でき (Git の学習曲線は重要であるため)、最終的には開発者としてより効果的になるような状況です。

集中型ツールを習得しようとしているとき、明らかに、リポジトリの他のユーザーに問題を引き起こす何か間抜けを作ることを心配するでしょう。恥ずかしいという恐怖だけで、人々は実験を思いとどまらせるのに十分です。特別な「トレーニング」リポジトリを用意しても役に立ちません。開発者は、トレーニング中に見たことのない状況に本番システムで遭遇することは避けられず、再び心配することになるからです。

しかし、Git の分散型の性質はこれを排除します。ローカル ブランチで任意の実験を試すことができます。それがひどく失敗した場合は、ブランチを破棄して、誰も知る必要はありません。あらゆるもののローカル ブランチを作成できるため、実際のライブ リポジトリで発生している問題を再現できますが、「ビルドを壊す」などの危険はありません。きちんとした小さなパッケージにまとめて作業する必要はなく、完了したらすぐにすべてをチェックインできます。つまり、今日 4 時間かけて行った 2 つの主要なコード変更だけでなく、途中で覚えていたビルドの修正や、同僚に何かを説明しているときに見つけたドキュメントのスペルミスなども含まれます。そして、プロジェクトの方向性が変わったために大きな変更が断念された場合、

于 2008-10-22T13:28:50.700 に答える
9

個人的に git で私を売り込んだコマンドはbisectでした。現時点では、この機能が他のバージョン管理システムで利用できるとは思いません。

そうは言っても、ソース管理用の GUI クライアントに慣れている人は、git に感銘を受けることはないでしょう。現在、フル機能のクライアントはコマンドラインのみです。

于 2008-10-21T17:52:33.897 に答える
9

人々はどの Perforce 機能を使用していますか?

  • 1 台のマシンに複数のワークスペース
  • 番号付きチェンジリスト
  • 開発者ブランチ
  • IDE との統合 (Visual Studio、Eclipse、SlickEdit など)
  • 多くのビルドバリアント
  • 複合ワークスペース
  • 一部の修正を統合するが他の修正を統合しない
  • 等

すべての人がコマンド ラインからの get と put を行っている場合、git はそれをカバーしており、他のすべての RTS もそうしているためです。

于 2008-10-21T18:56:02.240 に答える
6

どうやらGitHub は企業に git トレーニング コースを提供するようになりました。それについての彼らのブログ投稿を引用してください：

ここ数週間、Git で Android をトレーニングするのを手伝うために、Google キャンパスに何度も行ってきました。私は Shawn Pearce (Git と EGit/JGit の栄光で彼を知っているかもしれません。彼は Junio が町を離れたときにメンテナンスを引き継ぐヒーローです) から、Andriod に取り組んでいる Google エンジニアの移行中のトレーニングを手伝ってほしいと頼まれました。 Perforce から Gitまで、Android を大衆と共有することができました。私はそれをすることができてとても幸せだったと言えます。

[…]

Logical Awesome は現在、この種のカスタム トレーニング サービスをすべての企業に正式に提供しています。Git への切り替えを検討している場合は、組織のトレーニングと計画を支援できます。

鉱山を強調します。

于 2008-10-23T21:49:44.963 に答える
4

私は長い間 Perforce を使用してきましたが、最近 GIT も使用し始めました。これが私の「客観的な」意見です。

PERFORCE の機能:

  1. GUIツールはより機能が豊富なようです（タイムラプスビュー、リビジョングラフなど）
  2. 最新のリビジョンに同期するときの速度 (履歴全体を転送するオーバーヘッドがない)
  3. Eclipse/Visual Studio の統合は本当に素晴らしい
  4. チェンジリストごとに 1 つのブランチで複数の機能を開発できます (これが GIT よりも優れているかどうかはまだ 100% 確信が持てません)。
  5. 他の開発者が何をしているのか、つまり、彼らがチェックアウトしたファイルの種類を「スパイ」することができます。

GIT の機能:

  1. GITのコマンドラインはPerforceよりもずっとシンプルだという印象を受けました（init/clone、add、commit。複雑なワークスペースの構成はありません）
  2. チェックアウト後にプロジェクト履歴にアクセスするときの速度 (同期時に履歴全体をコピーするという犠牲が伴います)
  3. オフライン モード (開発者は、P4 サーバーに到達できないためにコーディングが禁止されていることに文句を言うことはありません)
  4. 新しいブランチの作成ははるかに高速です
  5. 各開発者は独自のローカル サンドボックスを持つことができるため、「メイン」GIT サーバーには十分な TBytes のストレージは必要ありません。
  6. GIT はオープンソースです - ライセンス料はかかりません
  7. あなたの会社がオープンソース プロジェクトにも貢献している場合、パッチの共有は GIT を使用するとはるかに簡単になります。

全体として、オープンソース/分散プロジェクトでは常に GIT をお勧めします。GIT は P2P アプリケーションに似ており、誰もが開発に参加できるからです。たとえば、Perforce でリモート開発を行っていたとき、1 Mbps のリンクを介して 4 GB のプロジェクトを週に 1 回同期していたことを覚えています。そのせいで多くの時間が無駄になりました。また、そのためには VPN をセットアップする必要がありました。

小規模な会社で、P4 サーバーが常に稼働している場合、Perforce も非常に優れたオプションであると言えます。

于 2011-02-15T23:37:29.093 に答える
3

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 のオプションではないのか理解できません。

この動作を実現する唯一の方法は、ファイルをバイナリとしてマークすることです。私が見たように、それは不足している機能を回避するための厄介なハックです。すべてのスクリプトなどでやらなければならないのは面倒なこととは別に、おそらくほとんどの差分などを壊してしまうでしょう。

現時点で解決した「解決策」は、スクリプトが Unix 環境にデプロイされるたびに、sed コマンドを実行してスクリプトからすべてのキャリッジ リターンを削除することです。これも理想的ではありません。特に、それらの一部は WAR ファイル内にデプロイされており、展開時に sed 行を再度実行する必要があるためです。

これは、GIT に大きな利点をもたらすと私が考えるものであり、上記では言及されていないと思います。

編集:Perforceをもう少し長く使用した後、さらにいくつかのコメントを追加したいと思います:

A) 私が Perforce で本当に見逃しているのは、変更、削除、追加されたファイルを含む明確なインスタンスの差分です。これはgit diffコマンドを使用して GIT で利用できますが、Perforce では、変更を記録する前にファイルをチェックアウトする必要があります。編集時にファイルを自動的にチェックアウトするようにメイン エディター (Eclipse など) を設定している場合でも、他の方法 (メモ帳、UNIX コマンドなど) でファイルを編集することがあります。また、Eclipse と p4eclipse を使用しても、新しいファイルが自動的に追加されないように見えます。したがって、すべての変更を見つけるには、ワークスペース全体で「Diff against...」を実行する必要があります。これには、まず実行に時間がかかり、次に、非常に複雑な除外リストを設定しない限り、あらゆる種類の無関係なものが含まれます。それは私を次のポイントに導きます。

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 では、変更を実際にプッシュしないため、変更をコミットすることができます。プッシュする前に他の変更に取り組むことはできますが、以前の変更もプッシュしない限り、後で追加するものをプッシュすることはできません。

于 2012-04-13T09:24:55.873 に答える
3

Perforce と git (および最も一般的に言及されているもの) の重要な違いの 1 つは、巨大なバイナリ ファイルのそれぞれの処理です。

たとえば、ビデオ ゲーム開発会社の従業員のこのブログのように: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html

ただし、重要なことは、ドキュメントからこれまでにビルドされたすべてのバイナリ (そして最後に、実際のソース履歴) までのすべてを含む 6 GB の巨大なリポジトリがある場合、git と perforce の速度の違いは通常、大企業は Perforce を実行する傾向があるため、すべての重要な操作を地下にある巨大なサーバー バンクにオフロードするように設定しています。

Perforce 側のこの重要な利点は、Perforce とはまったく関係のない要因、つまり、Perforce を実行している会社が前述のサーバー バンクを購入できるという事実からのみもたらされます。

とにかく、結局のところ、Perforce と git は別の製品です。Git は VCS としてのみ設計されており、これは Perforce よりもはるかに優れています (より多くの機能があり、一般的に使いやすいという点で、特に別の言葉で言えば、Perforce での分岐はオープンハートを実行するようなものです)。手術、それは専門家だけが行うべきです:P ) ( http://stevehanov.ca/blog/index.php?id=50 )

Perforce を使用する企業が得られるその他の利点は、単に Perforce が単なる VCS ではなく、ファイル サーバーでもあり、ビルドのパフォーマンスをテストするためのその他の機能を多数備えているという理由だけで得られます。

最後に: Git はオープンソースであり、起動がはるかに柔軟であるため、git にパッチを適用して重要な操作を中央サーバーにオフロードし、多数の高価なハードウェアを実行することはそれほど難しくありません。

于 2012-04-03T03:39:11.587 に答える
2

Git の経験はありませんが、分散型 VCS でもある Mercurial の経験はあります。それは実際にはプロジェクトに依存しますが、私たちの場合、頻繁に壊れたビルドを基本的に排除するため、分散型 VCS がプロジェクトに適していました。

クライアントサーバーVCSに適しているものもあれば、分散型VCSに適しているものもあるため、実際にはプロジェクトに依存していると思います。

于 2008-10-21T17:57:30.270 に答える
-5

これが私がgitについて好きではないことです：

まず第一に、分散されたアイデアは現実に直面して飛んでいると思います。実際にgitを使用している人は誰でも、Linus Torvaldsを含め、一元化された方法で使用しています。カーネルが分散して管理されている場合、「公式」カーネルソースを実際にダウンロードできなかったことを意味します。つまり、カーネルソースはありません。LinusバージョンとJoeバージョンのどちらが必要かを判断する必要があります。またはビルのバージョン。それは明らかにばかげているでしょう、そしてそれが一元化されたワークフローを使用してLinusが制御する公式の定義がある理由です。

一元化された定義が必要であることに同意すると、サーバーとクライアントの役割が完全に異なることが明らかになるため、クライアントとサーバーソフトウェアを同じにする必要があるという教義は純粋に制限されます。クライアントとサーバーのデータが同じでなければならないという教義は、特に誰も気にしないが誰もがクローンを作成しなければならない15年の歴史を持つコードベースでは、明らかにばかげています。

私たちが実際にやりたいのは、通常のVCSと同じように、古いものをすべて食器棚に入れて、そこにあることを忘れることです。gitが毎日ネットワークを介してそれを前後に運ぶという事実は、それを整理するようにあなたを悩ませるので、非常に危険です。その剪定は多くの退屈な決定を伴い、それはうまくいかない可能性があります。したがって、人々はおそらく履歴のさまざまなポイントから一連のスナップショットリポジトリ全体を保持しますが、そもそもソース管理の目的ではなかったのでしょうか。この問題は、誰かが分散モデルを発明するまで存在しませんでした。

Gitは積極的に人々に歴史を書き直すことを奨励しており、上記がおそらくその理由の1つです。通常のVCSはすべて、管理者以外のすべてのユーザーが履歴を書き換えることを不可能にし、管理者がそれを考慮する理由がないことを確認します。私が間違っている場合は訂正してください。しかし、私が知る限り、gitは通常のユーザーに書き込みアクセスを許可する方法を提供していませんが、履歴の書き換えを禁止しています。つまり、恨みを持っている開発者（またはまだ学習曲線に苦労している開発者）は、コードベース全体を破壊する可能性があります。どうやってそれを締めますか？さて、あなたは歴史全体の定期的なバックアップを作成します、すなわちあなたは歴史を二乗し続けるか、またはあなたは電子メールですべてのdiffを受け取りそしてそれらを手でマージするいくつかの貧しいsodを除いてすべてへの書き込みアクセスを禁止します。

資金が豊富で大規模なプロジェクトの例を見て、gitがどのように機能しているかを見てみましょう：Android。私はかつてAndroidシステム自体で遊ぶことにしました。私は、repoと呼ばれる一連のスクリプトを使用してgitを取得することになっていることを知りました。一部のリポジトリはクライアントで実行され、一部はサーバーで実行されますが、どちらもその存在自体から、gitがどちらの容量でも不完全であるという事実を示しています。何が起こったのかというと、私は約1週間ソースを引き出すことができず、その後完全に諦めました。いくつかの異なるリポジトリから本当に膨大な量のデータを取得する必要がありましたが、サーバーは私のような人々で完全に過負荷になりました。レポはタイムアウトしていて、タイムアウトしたところから再開できませんでした。gitが非常に配布可能である場合、あなたはそれらが dは、その1台のサーバーの負荷を軽減するために、ある種のピアツーピア処理を実行しました。Gitは配布可能ですが、サーバーではありません。Git + repoはサーバーですが、repoは配布可能ではなく、ハックのアドホックコレクションにすぎません。

gitの不十分さの同様の例は、gitolite（および明らかにうまく機能しなかったその祖先）です。Gitoliteは、gitサーバーの展開を容易にすることとしてその仕事を説明しています。繰り返しになりますが、このことの存在自体が、gitがサーバーではなく、クライアントであるということを証明しています。さらに、それがどちらかに成長した場合、それはその創設の原則を裏切ることになるので、決してそうなることはありません。

配布されたものを信じていたとしても、gitはまだ混乱しているでしょう。たとえば、ブランチとは何ですか？リポジトリのクローンを作成するたびに暗黙的にブランチを作成すると言われていますが、それは単一のリポジトリのブランチと同じにすることはできません。つまり、少なくとも2つの異なるものがブランチと呼ばれています。ただし、レポで巻き戻して編集を開始することもできます。それは2番目のタイプのブランチのようなものですか、それともまた違うものですか？多分それはあなたが持っているレポのタイプに依存します-そうそう-どうやらレポはあまり明確な概念でもありません。普通のものとむき出しのものがあります。ベアパーツがソースツリーと同期しなくなる可能性があるため、通常のパーツにプッシュすることはできません。しかし、彼らがそれについて考えていなかった裸の1つのcosにcvsimportすることはできません。したがって、通常のものにcvsimportする必要があります。それを開発者がヒットしたベアのものに複製し、cvsexportをcvsワーキングコピーにエクスポートします。これはまだcvsにチェックインする必要があります。誰が気になりますか？これらすべての合併症はどこから来たのですか？配布されたアイデア自体から。これらの制限をさらに課していたので、最終的にジトライトを捨てました。

Gitは、分岐は軽いはずだと言っていますが、多くの企業はすでに深刻な不正な分岐の問題を抱えているので、分岐は厳格なポリシングを伴う重大な決定であるべきだと思いました。これは、PERFORCEが本当に輝いているところです...

PERFORCEでは、非常に機敏な方法でチェンジセットを調整できるため、ブランチが必要になることはめったにありません。たとえば、通常のワークフローでは、メインラインで最後に確認された正常なバージョンに同期してから、機能を記述します。ファイルを変更しようとすると、そのファイルの差分が「デフォルトのチェンジセット」に追加されます。チェンジセットをチェックインしようとすると、メインラインからのニュースをチェンジセットに自動的にマージ（事実上リベース）してからコミットします。このワークフローは、理解していなくても実施できます。このように、Mainlineは変更の履歴を収集します。これは、後で簡単に選択できます。たとえば、古いもの、たとえば前のものを前のものに戻したいとします。問題のある変更の前の瞬間に同期し、影響を受けるファイルを変更セットの一部としてマークし、直後に同期し、「alwaysmine」とマージします。（そこには非常に興味深いものがありました。同期は同じことを意味するわけではありません。ファイルが編集可能である場合（つまり、アクティブなチェンジセット内）、同期によって破壊されることはありませんが、解決の期限としてマークされます。）これで次のようになります。問題のあるものを元に戻すチェンジリスト。後続のニュースにマージすると、メインラインの上に配置して目的の効果を得ることができるチェンジリストがあります。どの時点でも、履歴を書き換えることはありませんでした。後続のニュースにマージすると、メインラインの上に配置して目的の効果を得ることができるチェンジリストがあります。どの時点でも、履歴を書き換えることはありませんでした。後続のニュースにマージすると、メインラインの上に配置して目的の効果を得ることができるチェンジリストがあります。どの時点でも、履歴を書き換えることはありませんでした。

さて、このプロセスの途中で、誰かがあなたに駆け寄り、すべてを削除してバグを修正するように指示します。デフォルトのチェンジリストに名前（実際には番号）を付けてから「一時停止」し、空になったデフォルトのチェンジリストのバグを修正してコミットし、名前付きチェンジリストを再開します。さまざまなことを試すときに、一度に複数のチェンジリストを一時停止するのが一般的です。簡単でプライベートです。メインラインにマージすることから先延ばしにしたり、鶏肉にしたりする誘惑なしに、ブランチレジームから本当に欲しいものを手に入れることができます。

理論的にはgitで同様のことを行うことは可能だと思いますが、gitは、承認されたワークフローを主張するのではなく、実質的に何でも可能にします。集中型モデルは、無効な一般化である分散型モデルに関連する一連の有効な簡略化です。それは非常に一般化されているので、基本的には、リポジトリのように、その上にソース管理を実装することを期待しています。

もう1つはレプリケーションです。gitでは、何でも可能であるため、自分で理解する必要があります。PERFORCEでは、事実上ステートレスキャッシュを取得します。知る必要がある唯一の構成はマスターがどこにあるかであり、クライアントは自分の裁量でマスターまたはキャッシュのいずれかを指すことができます。それは5分間の仕事であり、間違いはありません。

また、コードレビュー、Bugzilla参照などをアサートするためのトリガーとカスタマイズ可能なフォームがあり、もちろん、実際にそれらが必要な場合のブランチがあります。明確なケースではありませんが、近くにあり、セットアップと保守が非常に簡単です。

全体として、誰もが行うように一元化された方法で作業することがわかっている場合は、それを念頭に置いて設計されたツールを使用する方がよいと思います。ライナスの恐ろしいウィットと羊のようにお互いを追いかける傾向があるため、Gitは過大評価されていますが、その主な存在理由は実際には常識に反しており、それに従うことでgitは自分の手を結び付けます（a）ソフトウェアと（b）データはクライアントとサーバーの両方で同じでなければならないという2つの巨大な教義は、集中化された仕事では常に複雑で不十分なものになります。

于 2012-06-21T03:30:46.160 に答える
-8

不正なコード行管理の代わりにGITを使用するのが一般的です。Perforceの欠点の多くは、不適切な分岐戦略の結果です。他の集中型ツールについても同じです。大量のブランチを作成する必要がある場合は、何か間違ったことをしています。なぜ開発者はこれほど多くのブランチを作成する必要があるのですか？

また、なぜとにかく切断された作業がそれほど重要なのですか？誰かが電車で働くことができるように？最近、ワイヤレス接続ができないのはここだけです。そしてほとんどの電車でさえまともなWiFiを持っています。

于 2011-04-07T22:44:12.347 に答える