ですから、私はGITを職場で販売する過程にあります。私が最初に必要なことは、GITがすでに慣れていることで優れていることをすべての人に納得させることです。現在、PERFORCEを使用しています。他の誰かが同様の販売を経験しますか？良いリンク/アドバイスはありますか？
大きなメリットの1つは、ネットワークから切断された状態で作業できることです。もう1つの勝利IMOは、追加/チェックアウトの処理方法です。もっとポイントを歓迎します！また、合計で約10〜20人の開発者がいます。
ですから、私はGITを職場で販売する過程にあります。私が最初に必要なことは、GITがすでに慣れていることで優れていることをすべての人に納得させることです。現在、PERFORCEを使用しています。他の誰かが同様の販売を経験しますか？良いリンク/アドバイスはありますか？
大きなメリットの1つは、ネットワークから切断された状態で作業できることです。もう1つの勝利IMOは、追加/チェックアウトの処理方法です。もっとポイントを歓迎します！また、合計で約10〜20人の開発者がいます。
回答:
Perl 5インタープリターのソースコードは現在、PERFORCEからgitへの変換の苦境を乗り越えています。多分サムビランのgit-p4raw輸入業者は興味があります。
いずれにせよ、すべての集中型VCSに勝る大きな勝利のひとつであり、ほとんどの分散型の勝利も生の、猛烈なスピードです。あなたがそれを経験するまで、プロジェクトの歴史全体を手元に置いておくことがどれほど解放的であるかを想像することはできません。各コミットの完全な差分を含むプロジェクト履歴全体のコミットログを生成することでさえ、1秒未満で測定できます。Gitはとても速いので、帽子が飛び散ります。ネットワークを介してラウンドトリップする必要があるVCSは、ギガビットイーサネットリンクを介しても、競合する可能性がありません。
また、gitを使用すると、コミットを行うときに慎重に選択することが非常に簡単になります。これにより、作業コピーの変更（または単一のファイル内でも）を複数のコミットに分散でき、必要に応じてさまざまなブランチに分散できます。これにより、作業中のメンタルノートを減らすことができます。作業を慎重に計画する必要はなく、コミットする変更のセットを事前に決定し、他の変更は必ず延期します。必要に応じて変更を加えるだけで、コミットするときに、ほとんどの場合、非常に簡単に変更を解くことができます。隠し場所はここで非常に大きな助けになります。
これらの事実が合わさって、gitを使用する前よりもはるかに多くの焦点を絞ったコミットを自然に行うことができます。これにより、履歴が一般的に役立つだけでなく、などの付加価値ツールにとって特に有益になりますgit bisect。
今は考えられないことがもっとあると思います。チームをgitで販売するという提案の問題のひとつは、上記で示唆したように、多くの利点が相互に関連し、相互に作用し合うため、gitの機能と利点のリストを簡単に見て、それらがどのように機能するかを推測するのが難しいことです。ワークフローを変更し、どの変更が真の改善になるかを確認します。これを考慮に入れる必要があり、またそれを明示的に指摘する必要もあります。
私は仕事でPERFORCEを使用しています。また、コードで作業していてサーバーに接続できない場合でも、何らかのバージョン管理が必要なため、Gitを使用しています。いいえ、オフライン作業の調整は同じではありません。ここで、gitが大きなメリットであることがわかりました。
まあ、それは私の2セントです。PERFORCEの弁護では、私は彼らのカスタマーサポートルールを言わなければなりません、そして彼らのタイムラプスビューツールもそうです。gitでタイムラプスビューを取得する方法がわかりません。しかし、利便性と時間を節約するために、私はいつでもgitを使用します。
PERFORCEから切り替えるには多くの説得力が必要です。私が使用した2つの会社では、それで十分でした。どちらも異なるオフィスを持つ会社でしたが、オフィスには十分なインフラストラクチャが設定されていたため、分離/切断された機能を用意する必要はありませんでした。
何人の開発者が切り替えについて話しているのですか？
本当の問題は、gitが提供できる組織のニーズを満たしていないPERFORCEについてはどうでしょうか。同様に、gitはPERFORCEと比較してどのような弱点がありますか？自分で答えられない場合は、ここで質問しても役に立ちません。あなたはあなたの会社のビジネスケースを見つける必要があります。（たとえば、全体的な所有コストが低くなっている可能性があります（これには、中間学習段階での生産性の低下、（少なくとも最初は）管理コストの上昇などが含まれます）。
私はあなたが厳しい売りに出ていると思います-PERFORCEは取り替えようとするのにかなり良いものです。あなたがpvcsまたはssafeを起動しようとしているなら、それは簡単です。
切り替え中/切り替え後の人々を幸せに保つという観点から、早い段階で理解することの1つは、Gitでローカルブランチをどれだけプライベートにできるか、そして間違いを犯す自由がどれだけあるかということです。それらすべてに、現在のコードからいくつかのプライベートブランチのクローンを作成してもらい、そこで実験してみてください。一部のファイルの名前を変更したり、チェックインしたり、別のブランチのファイルをマージしたり、履歴を巻き戻したり、変更のセットを別のセットにリベースしたりします。彼らの最悪の事故でさえ、彼らの同僚にどのように影響を与えないかを示してください。必要なのは、開発者が安全だと感じて、より速く学習できるようにし（Gitには重要な急な学習曲線があるため）、最終的には開発者としてより効果的になる状況です。
一元化されたツールを学習しようとしているときは、明らかに、リポジトリの他のユーザーに問題を引き起こすいくつかの失敗をすることを心配するでしょう。恥ずかしさだけを恐れるだけで、人々が実験するのを思いとどまらせることができます。特別な「トレーニング」リポジトリを持っていても役に立ちません。開発者は必然的に、トレーニング中に見たことのない本番システムの状況に遭遇し、心配に戻るからです。
しかし、Gitの分散型の性質はこれを排除します。ローカルブランチで任意の実験を試すことができます。それがひどくうまくいかない場合は、ブランチを捨てるだけで、誰も知る必要はありません。あらゆるもののローカルブランチを作成できるため、実際のライブリポジトリで発生している問題を再現できますが、「ビルドを壊す」など、自分を馬鹿にする危険はありません。完了したらすぐに、すべてを完全にチェックインできます。きちんとした小さなパッケージにまとめて作業する必要はありません。したがって、今日4時間費やした2つの主要なコード変更だけでなく、途中で覚えていたビルド修正や、同僚に何かを説明しているときに見つけたドキュメントのスペルミスなどもあります。そして、プロジェクトが方向を変えているために大きな変更が放棄された場合、
個人的にgitで私を売ったコマンドはbisectでした。現在のところ、この機能は他のバージョン管理システムでは利用できないと思います。
そうは言っても、ソース管理のためのGUIクライアントに慣れている人は、gitに感銘を受けることはありません。現在、フル機能のクライアントはコマンドラインのみです。
git log --graphGitのリビジョン履歴は非線形であり、画像なしでは視覚化するのが難しい傾向があるため、GUI（または少なくとも）が必要です。私はGitXとSourceTreeをGUIとして使用していますが、gitk（現在Gitに付属しています）はピンチで通用します。
人々はどのPerforce機能を使用していますか？
すべての人がコマンドラインから取得して配置するだけであれば、gitがそれをカバーしているので、他のすべてのRTSもカバーしているので質問します。
どうやらGitHubは現在企業にgitトレーニングコースを提供しています。それについての彼らのブログ投稿を引用してください：
私は過去数週間に何度もGoogleキャンパスに行き、GitでAndroidをトレーニングするのを手伝っています。Shawn Pearce（彼のGitとEGit / JGitの栄光から彼を知っているかもしれません-彼はJunioが町を離れているときにメンテナンスを引き継ぐヒーローです）から、Andriodに移行するGoogleエンジニアのトレーニングを手伝ってくれるように頼まれました。PerforceからGitまで、Androidを大衆と共有できるようになりました。私はそれをすることがとても幸せだったとあなたに言うことができます。
[…]
現在、Logical Awesomeは、このタイプのカスタムトレーニングサービスをすべての企業に正式に提供しています。Gitへの切り替えを検討している場合は、組織のトレーニングと計画を支援できます。
強調鉱山。
私は長い間PERFORCEを使用してきましたが、最近GITも使用し始めました。これが私の「客観的な」意見です：
PERFORCEの機能：
GITの機能：
全体として、OpenSource / Distributedプロジェクトの場合、GITはP2Pアプリケーションに似ており、誰もが開発に参加できるため、常にGITをお勧めします。たとえば、PERFORCEでリモート開発を行っていたとき、週に1回、1Mbpsリンクを介して4GBプロジェクトを同期していたことを覚えています。そのため、多くの時間が無駄になりました。また、そのためにVPNを設定する必要がありました。
小さな会社があり、P4サーバーが常に稼働している場合は、PERFORCEも非常に優れたオプションだと思います。
しばらくの間Gitを使用していましたが、最近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=50）
PERFORCEを使用する企業がもたらすその他の利点は、PERFORCEがVCSだけでなく、ファイルサーバーでもあり、ビルドのパフォーマンスをテストするための他の多くの機能を備えているという理由だけでもたらされます。
最後に、Gitはオープンソースであり、起動がはるかに柔軟であるため、gitにパッチを適用して重要な操作を中央サーバーにオフロードし、高価なハードウェアの山を実行することはそれほど難しくありません。
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をもう少し長く使用した後、コメントをもう2つ追加したいと思います。
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では、実際にはプッシュされないため、変更をコミットするだけで済みます。それらをプッシュする前に他の変更に取り組むことはできますが、前の変更もプッシュしない限り、後で追加するものをプッシュすることはできません。
私はGitの経験はありませんが、分散型VCSでもあるMercurialを使用しています。それは実際にはプロジェクトに依存しますが、私たちの場合、分散型VCSは、基本的に頻繁に壊れたビルドを排除したため、プロジェクトに適していました。
クライアント/サーバーVCSに適しているものもあれば、分散型のVCSを使用しているものもあるため、プロジェクトによって異なります。
これが私がgitについて好きではないことです：
まず第一に、分散したアイデアは現実に直面していると思います。実際にgitを使用している人は誰でも、Linus Torvaldsを含め、一元化された方法で使用しています。カーネルが分散方式で管理されている場合、「公式」カーネルソースを実際にダウンロードできなかったことを意味します。カーネルソースはありません。LinusバージョンとJoeバージョンのどちらが必要かを判断する必要があります。またはビルのバージョン。それは明らかにばかげているでしょう、そしてそれがLinusが一元化されたワークフローを使用して制御する公式の定義がある理由です。
一元化された定義が必要であることに同意すると、サーバーとクライアントの役割が完全に異なることが明らかになるため、クライアントとサーバーソフトウェアを同じにする必要があるという教義は純粋に制限されます。クライアントとサーバーのデータが同じでなければならないという教義は、特に誰も気にしないが誰もがクローンを作成しなければならない15年の歴史を持つコードベースでは、明らかにばかげています。
私たちが実際にすべての古いものでやりたいのは、通常のVCSと同じように、食器棚にそれをぶつけて、そこにあることを忘れることです。gitが毎日ネットワークを介してそれをやり取りするという事実は、それを取り除くようにあなたを悩ませるので、非常に危険です。その剪定は多くの退屈な決定を伴い、それはうまくいかない可能性があります。したがって、人々はおそらく履歴のさまざまなポイントから一連のスナップショットリポジトリ全体を保持しますが、そもそもそれがソース管理の目的ではなかったのでしょうか。この問題は、誰かが分散モデルを発明するまで存在しませんでした。
Gitは積極的に人々に歴史を書き直すことを奨励しており、上記がおそらくその理由の1つです。通常のVCSはすべて、管理者以外のすべてのユーザーが履歴を書き換えることを不可能にし、管理者がそれを考慮する理由がないことを確認します。私が間違っている場合は訂正してください。しかし、私が知る限り、gitは通常のユーザーに書き込みアクセスを許可する方法を提供していませんが、履歴の書き換えを禁止しています。つまり、恨みを持っている（またはまだ学習曲線に苦労している）開発者は、コードベース全体を破壊する可能性があります。どうやってそれを締めますか？履歴全体の定期的なバックアップを作成するか、履歴を二乗しておくか、すべての差分を電子メールで受信して手動でマージする一部の貧しい芝を除くすべてへの書き込みアクセスを禁止します。
資金が豊富で大規模なプロジェクトの例を見て、gitがどのように機能しているかを見てみましょう：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参照などをアサートするためのトリガーとカスタマイズ可能なフォームもあります。もちろん、実際に必要なときのためのブランチもあります。明確なケースではありませんが、近くにあり、セットアップと保守が非常に簡単です。
全体として、誰もが行うように一元化された方法で作業することがわかっている場合は、それを念頭に置いて設計されたツールを使用する方がよいと思います。Linusの恐ろしい機知と、羊のようにお互いを追いかける傾向があるため、Gitは過大評価されていますが、その主な存在理由は実際には常識に反しており、Gitはそれに従うことで自分の手を結び付けています（a）ソフトウェアと（b）データはクライアントとサーバーの両方で同じでなければならないという2つの巨大なドグマは、集中化されたジョブでは常に複雑で不十分なものになります。
不正なコード行管理の代わりにGITを使用するのが一般的です。PERFORCEの欠点の多くは、不適切な分岐戦略の結果です。他の集中型ツールについても同じです。大量のブランチを作成する必要がある場合は、何か問題があります。なぜ開発者はこれほど多くのブランチを作成する必要があるのですか？
また、なぜとにかく切断された作業がそれほど重要なのですか？誰かが電車で働くことができるように？最近はワイヤレス接続ができないのはここだけです。そしてほとんどの電車でさえまともなWiFiを持っています。