吉特对比Perforce- 两个 VCS 将进入……一个将离开 [关闭]

StackOverflow https://stackoverflow.com/questions/222782

题

所以我正在工作中推销 GIT。我需要做的第一件事是让每个人相信 GIT 更擅长他们已经习惯做的事情。我们目前使用 Perforce。还有其他人经历过类似的销售吗？有什么好的链接/建议吗？

最大的胜利之一是我们可以在与网络断开的情况下使用它。IMO 的另一个胜利是添加/结帐的处理方式。欢迎更多积分！我们总共有大约 10-20 名开发人员。

有帮助吗？

解决方案

Perl＆nbsp; 5解释器源代码目前正在经历从Perforce转换为git的阵痛。也许Sam Vilain＆＃8217; git-p4raw 导入器很有意思。

在任何情况下，您在每个集中式VCS和大多数分布式VCS上获得的主要胜利之一也是原始的，强烈的 速度 。你无法想象将整个项目历史放在手边是多么的自由，只有几分之一秒的距离，直到你经历过它。即使为每个提交生成包含完整差异的整个项目历史记录的提交日志，也可以在几分之一秒内进行测量。 Git是如此之快，你的帽子会飞走。必须通过网络往返的VCS根本没有竞争机会，甚至不能通过千兆以太网链路进行竞争。

此外，git使得在提交时非常容易谨慎选择，从而允许更改工作副本（甚至在单个文件中）以分散多次提交＆＃8211;如果你需要，可以跨越不同的分支机构。这使您可以在工作时减少心理记录。你不需要如此仔细地计划你的工作，预先决定你将做出什么样的改变，并确保推迟其他任何改变。您可以随心所欲地进行任何您想要的更改，并且仍然可以解开它们并且＃8211;几乎总是很容易＆＃8211;什么时候提交。 藏匿在这里可以提供非常大的帮助。

我发现，总而言之，这些事实使我自然会比使用git之前做出更多更集中的提交。这反过来不仅使您的历史记录更有用，而且特别有利于增值工具，例如 git bisect 。

我确定现在还有更多我能想到的事情。使用git销售团队的建议的一个问题是，许多好处是相互关联的，并且相互影响，正如我在上面暗示的那样，因此很难简单地查看git的功能和优点列表并推断它们是如何将改变你的工作流程，哪些变化将是真正的改进。您需要考虑到这一点，并且还需要明确指出它。

其他提示

我在工作中使用Perforce。我也使用Git，因为当我处理代码并且无法连接到服务器时，我仍然会喜欢某种形式的版本控制。不，调和离线工作就不一样了。在这里，我发现git是一个很大的好处：

  1. 分支速度 - git最多需要几秒钟。
  2. 冲突 - P4Merge的自动解决方案摧毁了一周的工作量。从那时起，我宁愿在合并时手工解决。当Git提示我冲突时，实际上是一场冲突。剩下的时间里，git正确地解决了问题，我节省了很多时间。
  3. 跟踪合并 - 如果您有一个分支机构不断接收来自其他两个分支机构的合并，您就会知道perforce可能会让您感到头疼。使用git，头痛最小化，因为git中的合并结果实际上是一个新的提交，它知道它的祖先是谁。
  4. 权限 - 我已经忘记了我尝试处理文件的次数，但由于未在Perforce中检出，因此无法完成。如果您使用XCode（或任何没有可靠的Perforce SCM插件的编辑器）离线工作，您就会知道这有多么令人恼火。我不必为Git担心。我做了我的改变。 Git不会阻止我并在后台跟踪它们。
  5. 保持主树整洁 - 使用git，我可以对提交进行排序并整理代码，以便历史看起来整洁。这些都不是“检查此文件，因为它应该是之前签入的一部分”。垃圾。我压扁这样的提交，因为他们帮助没人。
  6. Stashing - 您的perforce服务器需要是版本2010.1或更高版本才能使用p4 shelve命令。
  7. 创建补丁 - 在git中很容易。不知道在不使用命令行的情况下Perforce是否可行。
  8. 从GUI发送补丁 - 再次，git在这里获胜。
  9. 磁盘空间 - 使用perforce，每个分支都是一个副本。这意味着如果您的源代码树很大，您的磁盘空间就会快速耗尽。一旦开始构建，这甚至不计算额外空间。为什么甚至在分支和磁盘空间之间建立链接？使用git，您可以拥有100个分支，并且一次只存在一个分支。如果您特别希望同时处理两个版本，您可以克隆，完成您的工作，然后根据需要删除一个克隆，而不会丢失任何内容。
  10. 如果您使用的是XCode4，则会删除perforce支持，并且内置git支持。如果您像我一样跨平台工作，这很重要。使用Visual Studio，您可以使用git扩展。使用perforce，它同样适用于两种操作系统。嗯，现在可能还有更多关于Mac的XCode4现场。
  11. 找到错误的签入（或者，git bisect规则） - 曾经尝试用perforce进行二进制搜索以找出错误的引入位置？相当麻烦，是吗？当中间的其他分支集成时，更麻烦。为什么？因为这些任务没有自动化。你需要编写自己的工具来与perforce交谈，而你通常没有时间。使用git，您可以给它起点（“好”点和“坏”点）并自动搜索。更好的是，如果你有一个可以自动构建和测试过程的脚本，你可以将git挂钩到脚本，并且查找签入的整个过程是自动的。应该是这样的。
  12. 跟踪重构之间的变化 - 尝试将BigClass拆分为SmallClass1和SmallClass2。对于Perforce，BigClass现在已不复存在，并且有两个新类（SmallClass1和SmallClass2已加入源树）。对于Perforce，BigClass与SmallClass1和SmallClass2之间没有任何关系。另一方面，Git非常聪明，知道BigClass的x％现在在SmallClass1中，而BigClass的y％在SmallCl中

从perforce转换我需要很多说服力。我使用它的两家公司绰绰有余。这些都是办公室不同的公司，但办公室设置了充足的基础设施，因此不需要具有不相交/断开的功能。

有多少开发人员在谈论转换？

真正的问题是 - 对于不能满足git可以提供的组织需求的perforce，它是什么？同样，git与perforce相比有哪些弱点？如果你不能自己回答，那么在这里询问将无济于事。您需要为您的公司找到一个商业案例。 （例如，它可能具有较低的总体拥有成本（包括临时学习阶段的生产力损失，更高的管理成本（至少最初）等）。

我认为你是一个艰难的卖点 - perforce是一个非常好的尝试替换。如果你试图引导pvcs或ssafe，这是一个没有脑子的事情。

我认为，在转换期间/之后让人们满意的方面，早期遇到的一件事就是本地分支机构在Git中的私密程度，以及让他们犯错误的自由度。让他们全部克隆当前代码中的一些私有分支，然后在那里疯狂，进行实验。重命名一些文件，检查内容，合并来自另一个分支的内容，回滚历史记录，将一组更改重新组合在另一个上面，依此类推。显示当地最严重的事故对他们的同事没有任何影响。你想要的是开发人员感到安全的情况，这样他们就可以更快地学习（因为Git有一个非常重要的学习曲线），然后最终使他们作为开发人员更有效。

当您尝试学习集中式工具时，显然您会担心会为存储库的其他用户造成问题。仅仅害怕尴尬就足以阻止人们进行实验。即使有特殊的“训练”存储库没有帮助，因为开发人员不可避免地会遇到生产系统中他们在培训期间从未见过的情况，因此他们又回到了担忧状态。

但是Git的分布式性质消除了这一点。您可以尝试在本地分支中进行任何实验，如果它出现严重错误，只需将分支扔掉，没人需要知道。由于您可以创建任何东西的本地分支，因此您可以复制您在实际存储库中看到的问题，但没有“破坏构建”的危险。或以其他方式欺骗自己。你可以检查所有内容，一旦你完成它，不要尝试批量处理整齐的小包。因此，不仅仅是你今天花了四个小时的两个主要代码更改，而且还有你记得中途的构建修复，以及你在向同事解释内容时发现的文档中的拼写错误，等等。如果由于项目正在改变方向而放弃了重大更改，您可以从分支中挑选构建修复和拼写错误，并保持那些没有麻烦。

在git上亲自卖给我的命令是平分。我认为此功能在目前的任何其他版本控制系统中都不可用。

话虽这么说，如果人们习惯使用GUI客户端进行源代码控制，他们就不会对git印象深刻。现在唯一的全功能客户端是命令行。

人们使用的Perforce功能是什么？

  • 单台计算机上的多个工作区
  • 编号更改列表
  • 开发人员分支
  • 与IDE集成（Visual Studio，Eclipse， SlickEdit，...）
  • 许多构建变体
  • 复合工作区
  • 集成一些修复而不是其他修复
  • 等

我问，因为如果所有人都在从命令行获取和放置，那么git已经覆盖了所有其他RTS。

显然 GitHub现在向公司提供git培训课程。请他们关于它的博客文章：

  

在过去的几周里，我已经多次到谷歌校园帮忙训练Git中的机器人。我被Shawn Pearce问过（你可能从他的Git和EGit / JGit荣耀中认识他＆＃8211;他是Junio离开城镇时接管维护的英雄）来帮助他培训Google工程师Andriod在从Perforce过渡到Git ，因此Android可以与群众分享。我可以告诉你，我非常乐意这样做。

     

[＆＃8230;]

     

Logical Awesome现在正式向所有公司提供这种定制培训服务，我们可以为您的组织提供帮助如果您正在考虑转换到Git，那么需要进行培训和计划。

强调我的。

我一直在使用Perforce很长一段时间，最近我也开始使用GIT。这是我的“目标”观点：

Perforce功能：

  1. GUI工具似乎功能更丰富（例如时间推移视图，修订图）
  2. 同步头版本时的速度（没有转移整个历史记录的开销）
  3. Eclipse / Visual Studio Integration非常好
  4. 您可以在每个Changelist的一个分支中开发多个功能（如果这比GIT更有优势，我仍然不能100％确定）
  5. 你可以“窥探”其他开发人员正在做什么 - 他们检查了哪种文件。

    6. GIT功能：

    1. 我得到的印象是GIT命令行比Perforce简单得多（init / clone，add，commit。没有配置复杂的工作区）
    2. 结账后访问项目历史时的速度（以同步时复制整个历史记录为代价）
    3. 离线模式（开发人员不会抱怨无法访问的P4服务器会阻止他们编码）
    4. 创建新分支的速度要快得多
    5. “主要” GIT服务器不需要足够的TBytes存储空间，因为每个开发人员都可以拥有自己的本地沙箱
    6. GIT是OpenSource - 没有许可费
    7. 如果您的公司也为OpenSource项目做出贡献，那么使用GIT
      8. 可以更轻松地共享补丁

      总的来说，对于OpenSource / Distributed项目，我总是会推荐GIT，因为它更像是一个P2P应用程序，每个人都可以参与开发。例如，我记得当我使用Perforce进行远程开发时，我每周会在1Mbps链路上同步4GB项目。由于这个原因，很多时间被浪费了。我们还需要设置VPN才能做到这一点。

      如果你有一家小公司并且P4服务器总是在运行，那么我会说Perforce也是一个非常好的选择。

我们一直在使用Git，最近我们的Git服务器的硬盘崩溃了，我们无法恢复到最新状态。我们设法回到了几天的状态。当服务器备份时。团队中的每个人都拉动/推动他们的变化，瞧，服务器又恢复到现状。

Perforce和git（以及最常提到的一个）之间的一个重要区别是它们各自处理巨大的二进制文件。

例如，在视频游戏开发公司的一位员工的博客中，例如： http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html

然而，重要的是，git和perforce之间的速度差异，当你拥有一个巨大的6gb存储库时，包含从文档到每个二进制构建的所有内容（最后，哦，是的！实际的源历史记录），通常大公司倾向于运行Perforce这一事实，因此他们将其设置为将所有重要业务卸载到地下室的巨大服务器银行。

Perforce的这一重要优势仅来自于与Perforce毫无关系的因素，运行它的公司可以负担得起服务器银行。

而且，无论如何，最终，Perforce和git是不同的产品。 Git被设计为仅仅是一个VCS，它比Perforce做得更好（因为它有更多的功能，通常更容易使用，特别是用另一个人的话来说，Perforce中的分支就像执行开心手术，只能由专家完成：P）（ http://stevehanov.ca/ blog / index.php？id = 50 ）

使用Perforce的公司获得的任何其他好处仅仅是因为Perforce不仅仅是一个VCS，它还是一个文件服务器，还有许多其他功能来测试构建的性能等。

最后：Git是开源的，启动起来更加灵活，将git卸载到中央服务器，运行大量昂贵的硬件也不会那么难。

我认为我知道GIT赢得的一件事是它能够“保留行结尾”。在所有文件上，而perforce似乎坚持将它们翻译成Unix，Dos / Windows或MacOS9格式（“\ n”，“\ r \ n”或“\ r \ n”）。

如果您在Windows环境或混合操作系统环境中编写Unix脚本，这真的很痛苦。甚至不可能在每个文件扩展名的基础上设置规则。例如，它会将.sh，.bash，.unix文件转换为Unix格式，并将.ccp，.bat或.com文件转换为Dos / Windows格式。

在GIT中（我不确定这是默认，选项还是唯一选项）您可以将其设置为“保留行结尾”。这意味着，您可以手动更改文件的行结尾，然后GIT将保留该格式。在我看来，这似乎是做事的理想方式，我不明白为什么这不是Perforce的选择。

实现此行为的唯一方法是将文件标记为二进制文件。正如我所看到的那样，这将是一个令人讨厌的黑客来解决一个缺失的功能。除了在所有脚本等上做繁琐之外，它还可能会破坏大多数差异等。

“解决方案”我们目前已经解决的问题是，每次将它们部署到Unix环境时，运行一个sed命令从脚本中删除所有回车。这也不理想，特别是因为其中一些部署在WAR文件中，并且sed行必须在解压缩时再次运行。

我认为这只是GIT的一大优势，我认为上面没有提到过。

编辑：在使用Perforce一段时间之后，我想补充几条评论：

A）Perforce中我真正想念的是一个明确的实例差异，包括更改，删除和添加的文件。这可以在GIT中使用 git diff 命令获得，但在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中有相当有用的变更列表。但是，假设我进行了一组更改，检查所有更改并将它们放在更改列表中，然后在提交更改列表之前处理其他内容。如果我稍后对第一个更改列表中包含的文件之一进行更改，那么该文件仍将在该更改列表中，并且我不能稍后提交更改列表，假设它仅包含我最初添加的更改（尽管它将是相同的文件）。在GIT中，如果您添加一个文件并对其进行进一步更改，则不会添加这些更改（并且仍会显示在 git diff 中，您将无法进行更改

我没有使用Git的经验，但我使用的Mercurial也是一个分布式VCS。它实际上取决于项目，但在我们的例子中，分布式VCS适合项目，基本上消除了频繁的破坏构建。

我认为这实际上取决于项目，因为有些更适合客户端服务器VCS，而其他人则更喜欢分布式项目。

以下是我不喜欢 git 的地方：

首先，我认为分布式的想法与现实背道而驰。每个真正使用 git 的人都以集中的方式进行操作，甚至 Linus Torvalds 也不例外。如果内核以分布式方式管理，那意味着我实际上无法下载“官方”内核源代码 - 不会有 - 我必须决定是否想要 Linus 的版本，还是 Joe 的版本，或比尔的版本。这显然是荒谬的，这就是为什么有一个由 Linus 使用集中式工作流程控制的官方定义。

如果您接受您想要对您的东西进行集中定义，那么很明显服务器和客户端角色完全不同，因此客户端和服务器软件应该相同的教条变得纯粹是限制性的。客户端和服务器的教条 数据 应该是一样的就变得明显荒谬了，特别是在一个有十五年历史的代码库中，没有人关心，但每个人都必须克隆。

我们真正想要做的就是把所有这些旧东西塞进柜子里，然后忘记它在那里，就像任何普通的 VCS 所做的那样。git 每天通过网络来回传输这些数据这一事实是非常危险的，因为它会催促你修剪它。这种修剪涉及很多繁琐的决定，而且可能会出错。因此，人们可能会保留历史上不同时间点的一系列快照存储库，但这不正是源代码控制的最初目的吗？直到有人发明了分布式模型，这个问题才存在。

Git 积极鼓励人们重写历史，上述可能就是原因之一。每个正常的 VCS 都使得除了管理员之外的所有人都无法重写历史记录，并确保管理员没有理由考虑它。如果我错了，请纠正我，但据我所知，git 没有提供任何方法来授予普通用户写入权限，但禁止他们重写历史记录。这意味着任何怀有怨恨的开发人员（或者仍在努力应对学习曲线的开发人员）都可能会破坏整个代码库。我们如何收紧这一点？好吧，要么定期备份整个历史记录，即你保持历史平方，或者你禁止对所有人进行写访问，除了一些可怜的草皮，他们会通过电子邮件接收所有差异并手动合并它们。

让我们举一个资金充足的大型项目的例子，看看 git 如何为他们工作：安卓。我曾经决定尝试一下android系统本身。我发现我应该使用一堆名为 repo 的脚本来获取他们的 git。一些 repo 运行在客户端上，一些运行在服务器上，但是两者的存在都说明了 git 在这两种能力上都是不完整的。发生的事情是，我在大约一周内无法获取源代码，然后完全放弃了。我必须从几个不同的存储库中提取大量数据，但服务器因像我这样的人而完全超载。Repo 超时，无法从超时位置恢复。如果 git 如此可分发，您可能会认为他们会做某种点对点的事情来减轻该一台服务器上的负载。Git 是可分发的，但它不是服务器。Git+repo 是一个服务器，但 repo 不可分发，因为它只是一个临时的 hack 集合。

git 的不足之处的一个类似例子是 gitolite （及其祖先，显然效果不太好。） Gitolite 将其工作描述为简化 git 服务器的部署。再次，这个东西的存在证明了 git 不是服务器，也不是客户端。更重要的是，它永远不会，因为如果它发展成任何一个，那就背叛了它的基本原则。

即使你确实相信分布式的​​东西，git 仍然会是一团糟。例如，什么是分支机构？他们说每次克隆存储库时都会隐式创建一个分支，但这与单个存储库中的分支不同。因此，至少有两种不同的事物被称为分支。但是，您也可以在存储库中倒回并开始编辑。这是否像第二种类型的分支，或者又是不同的东西？也许这取决于你拥有什么类型的回购协议 - 哦，是的 - 显然回购协议也不是一个非常清晰的概念。有普通的和裸露的。您无法推送到正常的部分，因为裸露的部分可能与其源树不同步。但你不能 cvsimport 到一个裸机，因为他们没有想到这一点。因此，您必须将 cvsimport 到一个普通的副本，将其克隆到开发人员点击的裸副本，然后将其 cvsexport 到仍需要签入 cvs 的 cvs 工作副本。谁能被打扰呢？所有这些并发症从何而来？来自分布式思想本身。我最终放弃了 gitolite，因为它对我施加了更多的限制。

Git 说分支应该是轻量级的，但许多公司已经存在严重的流氓分支问题，所以我认为分支应该是一个具有严格监管的重大决定。这就是“perforce”真正闪耀的地方......

实际上，您很少需要分支，因为您可以以非常敏捷的方式处理变更集。例如，通常的工作流程是同步到主线上最后一个已知的良好版本，然后编写您的功能。每当您尝试修改文件时，该文件的差异都会添加到您的“默认变更集”中。当您尝试签入变更集时，它会自动尝试将主线中的新闻合并到您的变更集中（有效地重新调整基础），然后提交。此工作流程是在您无需理解的情况下强制执行的。因此，主线收集了变化的历史记录，您可以在以后轻松地选择自己的方式。例如，假设您想要恢复旧的，例如前一个之前的那个。您同步到有问题的更改之前的时刻，将受影响的文件标记为变更集的一部分，同步到之后的时刻并与“始终是我的”合并。（那里有一些非常有趣的事情：同步并不意味着拥有相同的东西 - 如果文件是可编辑的（即在活动的变更集中）它不会被同步破坏，但会被标记为到期需要解决。）现在您有了一个可以撤消有问题的变更列表的变更列表。合并到后续新闻中，您将获得一个更改列表，您可以将其放在主线顶部以获得所需的效果。我们在任何时候都没有改写任何历史。

现在，假设在这个过程进行到一半时，有人跑到你面前并告诉你放下一切并修复一些错误。您只需为默认更改列表指定一个名称（实际上是一个数字），然后“暂停”它，修复现在空的默认更改列表中的错误，提交它，然后恢复指定的更改列表。当您尝试不同的事情时，通常会暂停多个变更列表。这既简单又私密。你可以从分支政权中得到你真正想要的东西，而不会受到拖延的诱惑，也不会因为合并到主线而犹豫不决。

我想理论上可以在 git 中做类似的事情，但 git 几乎使一切成为可能，而不是断言我们认可的工作流程。相对于分布式模型，集中式模型是一系列有效的简化，而分布式模型是无效的概括。它过于笼统，基本上希望您在其之上实现源代码控制，就像 repo 那样。

另一件事是复制。在 git 中，一切皆有可能，所以你必须自己解决。实际上，您将获得有效的无状态缓存。它需要知道的唯一配置是主服务器在哪里，客户端可以自行决定指向主服务器或缓存。这是一个五分钟的工作，而且不会出错。

您还拥有用于断言代码审查、bugzilla 引用等的触发器和可自定义表单，当然，您还可以在实际需要时使用分支。它不是很清晰，但很接近，并且非常容易设置和维护。

总而言之，我认为，如果您知道自己将以集中的方式工作（每个人都会这样做），那么您不妨使用专门为此设计的工具。Git 被高估是因为 Linus 的可怕智慧以及人们像绵羊一样互相追随的倾向，但它的主要存在理由实际上并不符合常识，通过追随它，git 束缚了自己的手脚。两个巨大的教条是（a）软件和（b）客户端和服务器上的数据必须相同，这总是会使集中式工作变得复杂和蹩脚。

使用GIT代替错误的代码行管理很常见。 Perforce的许多缺点是错误的分支策略的结果。对于任何其他集中式工具也是如此。如果你必须创造大量的分支，你做错了。为什么开发人员需要创建这么多分支？

另外，为什么工作断开如此重要呢？那么有人可以在火车上工作吗？这是有史以来唯一一个无法连接的地方。甚至大多数火车都有不错的WiFi。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top