GIT与Perforce –将有两个VCS进入…一个将离开[已关闭]

因此，我正在上班销售GIT。我需要做的第一件事就是说服所有人，GIT在他们已经习惯的情况下会更好。我们目前使用Perforce。其他人也有类似的交易吗？有什么好的链接/建议吗？

最大的成功之一是我们可以与网络断开连接。IMO的另一项胜利是处理添加/结帐的方式。欢迎更多积分！另外，我们共有大约10-20个开发者。

Perl 5解释器源代码目前正经历着从Perforce转换为git的苦恼。也许萨姆·维兰的git-p4raw进口商很感兴趣。

无论如何，您将要获得的每一个集中式VCS的主要胜利之一，也是大多数分布式VCS的胜利，是原始的，极快的速度。您无法想象拥有整个项目历史是多么的自由，只有几分之一秒的路程，直到您经历了它。即使生成整个项目历史的提交日志，其中包括每个提交的完整差异，也可以在几分之一秒内进行测量。Git太快了，你的帽子会飞起来。必须通过网络往返的VCS根本没有竞争的机会，甚至没有通过千兆以太网链路的竞争。

另外，git使得在提交时仔细选择起来非常容易，从而允许将工作副本（甚至单个文件中）的更改分散到多个提交中（如果需要的话）。这样一来，您在工作时就无需再进行任何心理记录了–您无需如此仔细地计划工作，无需事先决定要进行哪些更改，并确保将其他任何操作都推迟。您可以随时进行所需的任何更改，并在需要提交时几乎总是非常轻松地取消更改。藏起来可能对这里有很大帮助。

我发现，这些事实使我自然比起使用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. 存放-您的perforce服务器必须为2010.1版或更高版本才能使用p4 shelve命令。
7. 创建补丁-易于在git中进行。不知道在不使用命令行的情况下在Perforce中是否可行。
8. 从GUI邮寄补丁-再次，git在这里胜出。
9. 磁盘空间-使用perforce，每个分支都是一个副本。这意味着如果您的源代码树很大，那么磁盘空间就会很快被耗尽。一旦开始构建，这甚至不算额外的空间。为什么在分支机构和磁盘空间之间甚至存在链接？使用git，您可以有100个分支，一次只能存在一个分支。如果您特别想同时处理两个版本，则可以克隆，完成工作，然后根据需要摆脱一个克隆而不会丢失任何东西。
10. 如果您使用的是XCode4，则将取消对perforce的支持，并且现在已内置git支持。如果像我一样进行跨平台工作，那么这很重要。通过Visual Studio，您可以使用git扩展。使用perforce，在两个OS上都同样令人讨厌。好吧，现在在Mac上可能还有XCode4出现在Mac上。
11. 查找错误的签入（或git bisect规则）-是否曾经尝试用perforce进行二进制搜索以找出错误所在？很麻烦，是吗？当来自中间其他分支的集成变得更加麻烦。为什么？因为没有自动执行此类任务。您需要编写自己的工具来与perforce对话，而您通常没有时间。使用git，您可以为其指定起点（“好”点和“坏”点），并自动进行搜索。更好的是，如果您拥有一个可以自动执行构建和测试过程的脚本，则可以将git连接到该脚本，并且查找值机​​的整个过程是自动化的。那应该是这样。
12. 跨重构跟踪更改-尝试将BigClass拆分为SmallClass1和SmallClass2。对于Perforce而言，BigClass现在已不复存在，并且有两个新类（SmallClass1和SmallClass2已加入源树）。对于Perforce，BigClass与SmallClass1和SmallClass2之间没有关系。另一方面，Git非常聪明，可以知道BigClass的x％现在在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将是一场噩梦，因为它是封闭源代码，并且是最好的您可以做的只是猜测-仅将Google for Perforce迁移到Git即可了解我在说什么。至少使用它的开源Git，因此它消除了很多猜测。

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

从perforce转向我需要很多说服力。在我使用的两家公司中，这已经足够了。两家公司的办公室都不相同，但是办公室的基础设施很多，因此不需要脱节/脱节的功能。

您正在谈论有多少开发人员？

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

我认为您的销售很艰难-perforce是一个很好的替代产品。如果您尝试启动pvc或ssafe，这是没有问题的。

我认为，在让人们在切换期间/岗位切换过程中保持快乐的过程中，要尽早解决的问题之一就是Git中本地分支机构的私密性以及给他们犯错的自由度。让他们全部从当前代码中克隆一些私有分支，然后在那里疯狂尝试。重命名一些文件，签入内容，合并其他分支中的内容，倒带历史记录，将一组更改基于另一组更改，依此类推。展示即使在当地发生的最严重事故也不会对同事造成任何后果。您想要的是让开发人员感到安全的情况，这样他们可以更快地学习（因为Git的学习曲线很重要，这很重要），然后最终使他们作为开发人员更加有效。

当您尝试学习集中式工具时，显然您会担心制造一些问题，而这会给存储库的其他用户带来麻烦。仅凭尴尬就足以使人们不敢尝试。甚至拥有一个特殊的“培训”存储库也无济于事，因为开发人员不可避免地会遇到生产系统中在培训期间从未见过的情况，因此他们又会担心。

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

亲自将我卖给git的命令是二等分的。我认为目前尚无此功能在任何其他版本控制系统中提供。

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

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

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

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

显然，GitHub现在为公司提供了git培训课程。答曰他们的博客文章吧：

在过去的几周中，我曾多次去过Google校园，以帮助在Git培训Android。肖恩·皮尔斯（Shawn Pearce）要求我（您可能会从他的Git和EGit / JGit的荣耀中认识他-他是Junio外出时负责维护的英雄）来帮助他培训过渡时期从事Andriod工作的Google工程师从Perforce到Git，因此可以与大众共享Android。我可以告诉你，我很乐意这样做。

[…]

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

强调我的。

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

Perforce功能：

1. GUI工具似乎功能更丰富（例如，延时视图，修订图）
2. 同步至主修订版时的速度（无转移全部历史记录的开销）
3. Eclipse / Visual Studio集成真的很棒
4. 您可以在每个变更列表的一个分支中开发多个功能（我仍然不确定100％是否比GIT更具优势）
5. 您可以“监视”其他开发人员在做什么-他们签出了什么样的文件。

GIT功能：

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

总体而言，对于开源/分布式项目，我总是会推荐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

但是，重要的是，当您拥有庞大的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进行补丁以将重要的操作分担到中央服务器上运行并不难，运行大量昂贵的硬件。

我认为，我知道GIT胜出的一件事是它能够“保留所有文件的行尾”，而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 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中有相当有用的变更列表。但是，假设我进行了一组更改，将其全部检查并放入更改列表中，然后在提交该更改列表之前进行其他操作。如果以后我对第一个变更列表中包含的一个文件进行了更改，则该文件仍将在该变更列表中，并且我不能稍后再提交变更列表，前提是它仅包含我最初添加的变更（尽管将是相同的文件）。在GIT中，如果您添加文件并对其进行进一步更改，则这些更改将不会被添加（并且仍会显示在git diff并且您也必须先添加新更改才能提交文件。当然，这与更改列表的作用方式没有什么用，因为您只有一组添加的文件，但是在GIT中，您可以提交更改，因为实际上并没有推送更改。您可以让他们先进行其他更改，然后再进行推送，但是如果不先推送以前的更改，您将无法再推送以后添加的其他任何内容。

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

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

这是我不喜欢git的地方：

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

如果您接受要对内容进行集中定义的定义，那么服务器和客户端角色显然是完全不同的，那么客户端和服务器软件应该相同的信条就变成了纯粹的限制。客户端和服务器数据应该相同的教条显然变得荒谬，尤其是在已有15年历史的代码库中，没有人关心，但是每个人都必须克隆。

我们实际上想要用所有旧东西做的事情是将它装在柜子里，却忘了它在那里，就像任何普通的VCS一样。git每天都会在网络上来回拖拉它是非常危险的，因为它使您无法修剪它。修剪涉及许多繁琐的决定，并且可能会出错。因此，人们可能会从历史的各个角度保留一整套快照回购，但是这不是源代码控制的初衷吗？直到有人发明了分布式模型后，这个问题才出现。

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

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

git不足的一个类似例子是gitolite（其祖先显然做得不太好。）Gitolite将其工作描述为简化git服务器的部署。同样，这个东西的存在证明了git不是服务器，而是客户端。更重要的是，它永远不会，因为如果它发展成任一种，那就背叛了它的创立原则。

即使您确实相信分布式的​​东西，git仍然是一团糟。例如，什么是分支？他们说，每次克隆存储库时，您都隐式地创建了一个分支，但这与单个存储库中的分支是不一样的。因此，至少有两种不同的东西被称为分支。但是，然后，您也可以倒回存储库并开始编辑。就像第二种分支一样，还是有些不同？也许这取决于您拥有的回购类型-哦，是的-显然，回购也不是一个很明确的概念。有普通的和裸露的。您不能将其推入正常状态，因为裸露的部分可能与其源代码树不同步。但是您不能cvsimport到他们根本没有想到的一个cos。因此，您必须cvsimport到一个普通的，将其克隆到开发人员命中的裸机上，然后cvs将其导出到cvs工作副本，该副本仍必须检入cvs。谁可以打扰？这些并发症来自何处？从分布式想法本身开始。最后，我放弃了乙醇钠矿，因为它对我施加了更多的限制。

Git表示，分支应该是轻量级的，但是许多公司已经存在严重的流氓分支问题，因此我认为分支应该是一个严格的治安重大决策。这是perforce真正闪耀的地方...

在perforce中，您很少需要分支，因为您可以以非常敏捷的方式处理变更集。例如，通常的工作流程是您同步到主线上的最后一个已知的良好版本，然后编写功能。每当您尝试修改文件时，该文件的差异都会添加到“默认更改集”中。当您尝试签入变更集时，它将自动尝试将来自主线的新闻合并到变更集中（有效地重新定级），然后提交。该工作流程是强制执行的，您甚至不需要了解它。因此，Mainline收集了变更的历史记录，您可以很容易地在以后选择方法。例如，假设您要还原一个旧的，例如，一个在前一个在最后一个之前。您同步到有问题的更改之前，将受影响的文件标记为更改集的一部分，同步到那一刻，并与“ always mine”合并。（那里有一个非常有趣的东西：同步并不意味着拥有相同的东西-如果文件是可编辑的（即，处于活动变更集中），则同步不会破坏它，但将其标记为可解决。）现在，您有了更改列表，可以撤消违规的更改。合并后续新闻，您将拥有一个更改列表，您可以将其放置在主线顶部以产生所需的效果。我们从来没有重写任何历史记录。合并后续新闻，您将拥有一个更改列表，您可以将其放置在主线顶部以产生所需的效果。我们从未重写任何历史记录。合并后续新闻，您将拥有一个更改列表，您可以将其放置在主线上方以产生所需的效果。我们从未重写任何历史记录。

现在，假设在此过程中进行了一半，有人跑到您身边，告诉您放弃所有内容并修复一些错误。您只需给默认更改列表指定一个名称（实际上是一个数字），然后“挂起”它，修复现在为空的默认更改列表中的错误，提交它，然后恢复命名的更改列表。通常，在尝试其他操作时会挂起多个变更列表。它既简单又私密。您可以从分支机构体系中真正获得所需的资源，而不会因拖延或与主线合并而陷入困境。

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

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

您还可以使用触发器和可自定义的形式来声明代码审阅，Bugzilla引用等，当然，您在实际需要它们时具有分支。这不是一个清晰的案例，但是很接近，而且设置和维护起来也很容易。

总而言之，我认为，如果您知道每个人都会以一种集中的方式工作，那么您不妨使用专为这一目的而设计的工具。Git之所以被高估是因为Linus的机智令人恐惧，加上人们倾向于像羊一样互相跟随，但是它的主要存在实际上并没有违背常识，通过遵循它，git将自己的双手与（a）软件和（b）数据在客户端和服务器上必须是两个相同的巨大教条，这在集中式工作中总是使它变得复杂而and脚。

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

另外，为什么断开工作仍然如此重要？只是为了有人可以在火车上工作？那是最近几天唯一无法无线连接的地方。甚至大多数火车都有不错的WiFi。