Git vs. Perforce：如何选择（以及何时共用二者）
关于使用Git vs. Perforce进行源代码管理存在很多争议。团队正在寻找理想的解决方案，让开发人员满意并支持DevOps。因此，决策者需要考虑很多事情。
在这里，我们分解了Git和Perforce之间的差异 – 以及如何一起使用这些工具。
Git和Perforce有什么区别？
不同的团队有不同的需求。Git可能是一个团队的好选择; Perforce可能是另一个的正确的版本控制选择。
原生的，开源的Git可以很好地工作。对于只有少量开发人员和快速发布周期的纯代码项目尤其如此。其中一个例子是网站开发。
使用Perforce的企业版控制也是一个不错的选择。对于包含各种数字资产的复杂项目的大型团队来说尤其如此。例如，通过游戏开发和半导体公司，Perforce解决方案有助于集成所有数字资产（如二进制文件和设计文件）并确保其安全。
Perforce与Git比较
让我们看下一些关键的差异。
集中与分布式模型
Git是分布式的
通过分布式Git模型，开发人员可以将源代码 – 以及完整版本历史记录 – 下载到他们的计算机上。然后他们就可以在本地进行更改。这使得本地提交，差异和合并比较迅速。
但是，一个开发人员团队 – 每个人都拥有自己的仓库副本 – 需要协调来共享变更。那么问题是，谁的存储库是主人？您的公司也可能存在安全问题。在其计算机上具有存储库副本的每个开发人员可能难以管理。这就是今天越来越多的团队使用集中式Git模型的原因。打算成为项目一部分的更改将作为拉取或合并请求提交给主分支。这是针对专用的Git服务器而不是某个特定开发人员的工作站完成的。
在repo级别分配Git权限。因此，具有安全性要求的团队通常会将其项目分成几个存储库。这可确保开发人员只能访问他们需要的存储库。这使得审计更加容易。但是一旦项目被解散，团队需要处理跨存储库的依赖关系。
Perforce集中化
Helix Core – 来自Perforce的版本控制 – 具有集中模型。将所有内容存储在一个位置可确保开发人员始终拥有最新版本。开发人员无论身在何处，都会将所有更改提交到中央服务器。拥有一个项目副本可以在整个企业中创建单一的事实来源。这也改善了沟通工作，因为其他团队成员可以轻松看到正在进行的工作。Git正在进行中的状态仅存储在本地存储库中。
集中式模型使代码协作和代码重用变得更加容易。它确保了可审计性和可追溯性。尽管Helix Core是集中式的，但它通过副本和代理服务器安全地支持远程站点。这大大提高了性能，因为大多数操作都在本地完成。
性能
在性能方面，团队在比较Git和Perforce时经常会感到惊讶。
Git更快的地方
使用Git可以更快地进行本地提交，差异和合并。但许多开发者共同进行pull和push等操作会降低性能并降低生产力。
Perforce更快的地方
Helix Core专为速度和规模而设计。它可以处理每天数百万个事务，数十亿个文件和数 PB的存储。开发人员可以快速，轻松地查看他们的工作站上是否有最新版本的文件。此外，它处理具有独占锁定的大型二进制文件。这可以防止团队成员影响到彼此的工作。
借助Perforce Federated Architecture，远程团队可以体验大型clone/pull/build操作的本地速度性能。这可以减少传统Git的大部分WAN等待。
管理大文件/二进制文件
大文件和二进制工件是开发的一部分。它们可以是构建和输入测试的结果。但对于某些行业，比如游戏开发，它们是整个过程中不可或缺的一部分。您需要能够将美工和开发人员的工作结合到最终产品中。
Git提供LFS
今天，Git试图用Git LFS解决这个问题。但是大多数大型团队将他们的大型二进制资产存储在工件存储库工具中，如Nexus或Artifactory。这意味着您不再拥有单一的事实来源。这些额外的工具也使您的构建管道变得复杂。
Perforce将其存储在一个存储库中
在Helix Core中，工件与源代码和其他非代码资产一起存储。可以将这些工件作为相关源代码相同更改列表的一部分进行检入。将所有内容放在一个中央服务器中可以简化工作流程。您的管理员无需管理其他许可和集成。
分支
Git和Perforce都提供轻量级分支。尽管，两者的分支处理方式不同。
Git Branches
在Git中，当创建分支时，您可以立即开始在本地新分支上工作。在完成添加和更改并准备好提交之后，您可以合并或修改历史记录。但是，合并到主分支的本地副本与将更改推送到中央存储库不同。
如果在推送更改时多个开发人员正在处理相同的文件，则可能会出现合并冲突。这就是为什么在合并之前从服务器获取最新更改始终很重要的原因。但是如果你有数百名开发人员在Git上开展项目，那么这可能非常耗时。
如果您有跨存储库依赖关系，那么您需要在存储库之间协调合并冲突。这可能很棘手。随着你的团队或仓库数量的增长，它会越来越难。
Perforce Branches
在Helix Core中，分支在文件层次结构级别完成。您的团队成员可以选择要签出的特定文件并将其提交回存储库。独家结账可让开发人员了解其他人的工作内容。通过细化权限直至文件级别，管理员可以保护其最重要的文件。
Perforce Streams – 我们的分支和合并方式 – 简化了工作区设置并帮助指导团队。开发人员可以轻松地在流（分支）之间切换，很容易看到更改的传播方式。与Git一样，当提交对主流/分支的更改时，您仍然可能会发生冲突，但这些通常很容易管理。Helix Core的优势在于对正在进行的工作的可见性，以及潜在合并冲突的高级通知。
此外，Helix Core的可扩展性允许开发人员在单个操作中提交可能较大的更改列表，从而影响多个组件。这可以显着减少代码依赖性问题。这些可能是Git中的跨存储库依赖项。此外，可以轻松跟踪和管理这些更改。
那么为什么要使用Git？
有这么多团队使用Git的原因有很多。
正如我们所描述的，它解决了最基本的版本控制问题。它允许开发人员同时处理相同的代码，而无需重复工作。
它在本地的操作很快。而且Git通常是版本控制系统（VCS）开发人员在大学中第一个使用的。大多数开发人员都知道经常使用的Git命令，例如clone，commit和push。另外，它是免费的！
大企业Git的兴起
在过去几年中，许多商业公司已经开始秉承开源软件货币化的使命。GitHub，GitLab和Atlassian都是用Git完成的。他们添加了良好的用户界面，代码审查工作流程，多个存储库的管理功能以及与Git的管道集成。
与付费企业客户相比，这些Git提供商中的每一个都更受个人免费用户的欢迎。
GitHub，GitLab和Atlassian并不总是适用于企业软件开发团队。事实证明，Git的架构难以在该环境中扩展。
何时使用Perforce（Helix Core）
当您拥有以下内容时，Perforce是正确的版本控制系统：
大型代码库。
非代码资产，如二进制文件或图形。
代码依赖性，特别是跨组件。
广泛的代码重用，例如工件。
规模庞大，地域多样化的团队。
这是Perforce擅长的地方。这是因为我们的版本控制是为具有大型代码库和复杂开发环境的大型团队设计的。
Git vs. Perforce：无需选择
公司需要Perforce提供的可扩展优势。现在你可以获得这些好处 – 并且也可以使用Git。
这个复杂问题的解决方案不是两者相较选其一。您在Helix4Git中可以一起使用二者。
Helix4Git本地存储Git repos，具有Perforce Helix Core服务器的速度和可靠性。该解决方案在业界独一无二，支持您的DevOps发展。
Perforce for Git用户：Helix4Git
你的开发人员仍然可以使用Git命令，如merge和rebase，创建子模块，你可以命名它！这是因为他们可以访问任一解决方案 – 无需更改其工作流程或环境。
实际上，即使您的项目处于开发期间，也可以采用Helix4Git。这是无缝的。您可以将您的Git repos本地存储在Helix Core中，它也支持Git LFS工件。
一个核心的单一事实来源简化了持续集成/持续交付（CI / CD）。
Helix4Git使Git更快 – 速度提高80％，存储空间减少18％。
这意味着团队可以更快地获得所需的反馈。开发人员，发布经理和CI / CD团队在他们的生活中获得更多的时间。