85

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

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

4

14 回答 14

84

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

  1. 分支速度 - git 最多需要几秒钟。
  2. 冲突 - P4Merge 的自动解析一次破坏了一周的工作。从那以后，我宁愿在合并时手动解决。当 Git 提示我有冲突时，它实际上是一个冲突。其余时间，git 会正确解决问题，我节省了大量时间。
  3. 跟踪合并 - 如果您有一个分支不断接收来自其他两个分支的合并，您就会知道 perforce 会让人头疼。使用 git，头痛被最小化，因为在 git 中合并的结果实际上是一个新的提交，它知道它的祖先是谁。
  4. 权限 - 我忘记了我尝试处理文件的次数，但因为没有在 Perforce 中签出而无法处理。如果您离线使用 XCode（或任何没有可靠的 Perforce SCM 插件的编辑器），您就会知道这有多烦人。我不必担心 Git。我做出改变。Git 不会阻止我并在后台跟踪它们。
  5. 保持主树整洁 - 使用 git，我可以对提交进行排序并整理代码，以便历史看起来整洁。没有“签入此文件，因为它应该是先前签入的一部分”垃圾。我像这样压制提交，因为它们没有帮助任何人。
  6. 暂存 - 您的 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 足够聪明，知道现在 x% 的 BigClass 在 SmallClass1 中，y% 的 BigClass 在 SmallClass2 中，并且 BigClass 已不复存在。现在，从正在审查跨多个分支的更改的人的角度来看，您告诉我您会发现哪种方法更有用 - Git 或 Perforce。就个人而言，我更喜欢 Git 的方法，因为它更准确地反映了代码的实际变化。Git 能够做到这一点，因为它跟踪文件中的内容，而不是文件本身。
  13. 集中式或分散式：Git 是一个DVCS系统，而 perforce 是集中式的。中心化的 VCS 以后不能去中心化，但是 DVCS（尤其是 git）可以中心化。有几种产品可以为 git 添加非常细粒度的访问控制，如果这是业务需要的话。就个人而言，我会选择一个从长远来看能给我更大灵活性的系统。
  14. 分支映射：如果你想直接在 Perforce 中进行分支，你需要创建一个分支映射。这是有原因的，但它们与 Perforce 如何概念化分支有关。作为开发人员或团队，这仅仅意味着工作流程中的一个步骤，我认为这根本没有效率。
  15. 在团队之间共享工作：使用 Perforce，您不能拆分提交。A 团队正在开发功能 A。B 团队正在开发 B 功能。C 团队正在修复错误。现在，团队 A 和 B 必须修复一堆错误才能实现他们的功能。唯一的问题是，他们在提交更改时并没有那么自律（可能是因为他们赶在截止日期前），因此他们的“错误修复”是较大提交的一部分，其中还包含新内容，就其版本控制而言分支机构感到担忧。但是，C 团队现在正在做一个点发布，并希望从其他团队那里获得错误修复。如果他们使用 Git，C 团队可以挑选其他团队的相关更改，将它们拆分，只取他们需要的东西，而不用担心引入任何部分实现的功能。使用 Perforce，
  16. 更改平台 - 如果将来出于任何原因，您决定更改您选择的平台，使用 Perforce，您将受到 Perforce.com 的摆布以及您选择的平台的工具的可用性。
  17. 更改为未来令人惊叹的源代码控制引擎 X - 如果您决定更改用于源代码控制的内容，从 Perforce 中提取源代码控制历史并将其移动到新系统 X 将是一场噩梦，因为它是封闭源代码并且是最好的你可以做的就是猜测 - 只是谷歌的 Perforce 到 Git 迁移来了解我在说什么。至少对于它的开源 Git，它消除了很多涉及的猜测。

好吧，那是我的 2 美分。在 Perforce 的辩护中，我得说他们的客户支持规则，他们的 Time Lapse View 工具也是如此。我不知道如何使用 git 获得延时视图。但是为了方便和节省时间，我每天都会使用 git。

于 2010-05-06T03:54:25.993 回答
75

Perl 5 解释器源代码目前正在经历从 Perforce 转换为 git 的阵痛。也许 Sam Vilain 的git-p4raw进口商很有趣。

无论如何，您将在每个集中式 VCS 和大多数分布式 VCS 上获得的主要胜利之一也是原始的、极快的速度。在您亲身体验之前，您无法想象将整个项目历史放在手边是多么的解脱，仅仅几分之一秒。即使生成包含每个提交的完整差异的整个项目历史的提交日志，也可以在几分之一秒内进行测量。Git 太快了，你的帽子会飞的。必须通过网络往返的 VCS 根本没有竞争的机会，甚至在千兆以太网链路上也没有。

此外，git 可以很容易地在进行提交时进行仔细选择，从而允许将工作副本（甚至在单个文件中）中的更改分散到多个提交中——如果需要，还可以跨不同的分支进行更改。这可以让你在工作时做更少的心理笔记——你不需要那么仔细地计划你的工作，预先决定你将要进行哪些更改并确保推迟其他任何事情。您可以随心所欲地进行任何更改，并且仍然可以在需要提交时解开它们——几乎总是很容易。存储在这里可以提供很大的帮助。

我发现，与使用 git 之前相比，这些事实使我自然而然地做出了更多、更专注的提交。这反过来不仅使您的历史记录通常更有用，而且对增值工具（例如git bisect.

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

于 2008-10-21T23:41:43.477 回答
46

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

你说有多少开发人员要换人？

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

我认为您将面临艰难的销售 - perforce 是一个非常好的尝试替代。如果您尝试启动 pvcs 或 ssafe，这很容易。

于 2008-10-21T18:19:53.593 回答
15

我认为，在让人们在切换期间/切换后保持快乐方面，要尽早了解的一件事是本地分支在 Git 中的私密性，以及让他们犯错的自由度有多大。让他们都从当前代码中克隆一些私有分支，然后在那里疯狂地进行试验。重命名一些文件，签入，合并另一个分支的东西，倒回历史，将一组更改重新设置在另一组之上，等等。展示即使他们在当地发生的最严重的事故也不会对他们的同事造成任何后果。您想要的是开发人员感到安全的情况，因此他们可以更快地学习（因为 Git 具有陡峭的学习曲线，这一点很重要），然后最终使他们作为开发人员更有效。

当您尝试学习一个集中式工具时，显然您会担心做出一些错误，从而给存储库的其他用户带来问题。仅仅对尴尬的恐惧就足以阻止人们进行实验。即使拥有一个特殊的“培训”存储库也无济于事，因为开发人员不可避免地会在生产系统中遇到他们在培训期间从未见过的情况，因此他们又开始担心了。

但是 Git 的分布式特性消除了这一点。您可以在本地分支中尝试任何实验，如果出现严重错误，只需将分支扔掉，没人需要知道。由于您可以创建任何东西的本地分支，因此您可以使用真实的实时存储库复制您看到的问题，但不会有“破坏构建”或以其他方式自欺欺人的危险。您可以在完成后立即检查所有内容，无需尝试将工作批量整理成整洁的小包裹。因此，不仅是您今天花了四个小时进行的两个主要代码更改，还有您在中途记得的构建修复，以及您在向同事解释某些内容时发现的文档中的拼写错误，等等。如果因为项目正在改变方向而放弃了重大变更，

于 2008-10-22T13:28:50.700 回答
9

个人在 git 上卖给我的命令是bisect。到目前为止，我认为此功能在任何其他版本控制系统中都不可用。

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

于 2008-10-21T17:52:33.897 回答
9

人们正在使用哪些 Perforce 功能？

  • 单台机器上的多个工作区
  • 编号的更改列表
  • 开发者分支
  • 与 IDE 集成（Visual Studio、Eclipse、SlickEdit、...）
  • 许多构建变体
  • 复合工作区
  • 集成一些修复但不集成其他修复
  • ETC

我问是因为如果所有人都在做的是从命令行获取和放置，git 已经涵盖了这一点，所有其他 RTS 也是如此。

于 2008-10-21T18:56:02.240 回答
6

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

在过去的几周里，我多次到谷歌校园帮助训练那里的机器人使用 Git。Shawn Pearce（你可能从他的 Git 和 EGit/JGit 荣耀中认识他——当 Junio 不在城里时，他是接管维护的英雄）邀请我来帮助他培训在 Andriod 上工作的 Google 工程师进行过渡从 Perforce 到 Git，因此 Android 可以与大众共享。我可以告诉你，我很乐意这样做。

[…]

Logical Awesome 现在正式向所有公司提供这种类型的定制培训服务，如果您也在考虑切换到 Git，我们可以帮助您的组织进行培训和规划。

强调我的。

于 2008-10-23T21:49:44.963 回答
4

我已经使用 Perforce 很长时间了，最​​近我也开始使用 GIT。这是我的“客观”意见：

强制功能：

  1. GUI 工具似乎功能更丰富（例如延时视图、修订图）
  2. 同步到头部修订时的速度（没有传输整个历史的开销）
  3. Eclipse/Visual Studio 集成真的很棒
  4. 您可以在每个 Changelist 的一个分支中开发多个功能（我仍然不能 100% 确定这是否比 GIT 更有优势）
  5. 您可以“窥探”其他开发人员正在做什么——他们签出了什么样的文件。

吉特特点：

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

总的来说，对于开源/分布式项目，我总是推荐 GIT，因为它更像是一个 P2P 应用程序，每个人都可以参与开发。例如，我记得当我使用 Perforce 进行远程开发时，我每周一次通过 1Mbps 链接同步 4GB 项目。很多时间都因此被浪费了。我们还需要设置 VPN 来做到这一点。

如果您有一家小公司并且 P4 服务器将始终处于运行状态，那么我会说 Perforce 也是一个非常好的选择。

于 2011-02-15T23:37:29.093 回答
4

我们使用 Git 已经有一段时间了，最​​近我们的 Git 服务器的硬盘崩溃了，我们无法恢复到最新状态。我们设法回到了几天前的状态。当服务器备份时。团队中的每个人都拉/推了他们的更改，瞧，服务器回到了当前状态。

于 2011-12-30T04:22:09.217 回答
3

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

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

然而，重要的是，当你有一个巨大的 6gb 存储库时，git 和 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 回答
3

我认为我知道 GIT 获胜的一件事是它能够在所有文件上“保留行尾”，而 perforce 似乎坚持将它们转换为 Unix、Dos/Windows 或 MacOS9 格式（“\n”、“\ r\n" 或 "\r)。

如果您在 Windows 环境或混合操作系统环境中编写 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，这可能会很烦人。因此，要查找所有更改，您必须在整个工作区上运行“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 中，您可以只提交更改，因为这实际上并没有推送它们。您可以在推送它们之前让他们处理其他更改，但是如果不推送之前的更改，您将无法推送您稍后添加的任何其他内容。

于 2012-04-13T09:24:55.873 回答
2

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

我认为这真的取决于项目，因为有些更适合客户端-服务器 VCS，而另一些则更适合分布式 VCS。

于 2008-10-21T17:57:30.270 回答
-5

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

首先，我认为分布式的想法与现实背道而驰。每个实际使用 git 的人都以集中的方式这样做，即使是 Linus Torvalds。如果内核是以分布式方式管理的，那意味着我实际上无法下载“官方”内核源——不会有——我必须决定我想要的是 Linus 的版本，还是 Joe 的版本，或比尔的版本。这显然是荒谬的，这就是为什么有一个官方定义，Linus 使用集中式工作流来控制。

如果你接受你想要一个集中定义你的东西，那么很明显服务器和客户端角色是完全不同的，所以客户端和服务器软件应该相同的教条变得纯粹是限制性的。客户端和服务器数据应该相同的教条显然变得荒谬，尤其是在一个有 15 年历史的代码库中，没有人关心，但每个人都必须克隆。

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

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

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

git 不足的一个类似例子是 gitolite（它的祖先显然没有很好地工作。） Gitolite 将其工作描述为简化 git 服务器的部署。再一次，这个东西的存在证明了 git 不是一个服务器，就像它是一个客户端一样。更重要的是，它永远不会，因为如果它成长为任何一个，它就会背叛它的创始原则。

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

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

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

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

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

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

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

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

于 2012-06-21T03:30:46.160 回答
-8

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

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

于 2011-04-07T22:44:12.347 回答