开启本地git权限_不满足于Git？不妨试试用Perforce进行源代码管理

概述

关于使用Git vs. Perforce进行源代码管理的争论很多，如果您要评估Git与Perforce的关系，则需要考虑很多因素。最大的区别是Git是分布式的，而Perforce Helix Core是集中式的。Git和Perforce都有优缺点。在这里，我们涵盖了最大的4个差异，以帮助您选择最适合您的一个。

不同的团队有不同的需求，Git版本控制对于一个团队可能是一个不错的选择，Perforce可能是另一个合适的版本控制选择。对于只有少数开发人员和快速发布周期的仅代码项目，开源Git可以很好地工作。网站开发就是一个例子。

使用来自Perforce的企业版本控制也是一个不错的选择。对于具有复杂项目并包含各种数字资产的大型团队而言，尤其如此。例如，与游戏开发和半导体公司合作，Perforce解决方案可帮助集成所有数字资产（例如二进制文件和设计文件）并确保其安全。

Perforce与Git比较

2.1 集中式与分布式模型

Git是分布式的

使用分布式Git模型，开发人员可以将源代码以及完整的版本历史记录下载到他们的计算机上，然后，他们可以在本地进行更改。这样可以使本地提交，比较和合并快速进行。

但是，一组开发人员（每个人都有自己的存储库副本）需要协调变更共享。然后的问题是，谁的存储库是主存储库？您的公司可能也有安全问题，每个开发人员在其计算机上拥有存储库副本的操作都可能难以管理。因此，当今越来越多的团队使用集中化的Git模型，打算成为项目一部分的更改将作为请求或合并请求提交给master分支。这是针对专用的Git服务器，而不是针对某个特定开发人员的工作站。

Git权限在存储库(repo)级别分配，因此，对安全性有要求的团队通常将他们的项目分成几个存储库，这样可以确保开发人员只能访问他们需要的存储库，这使审核更加容易。但是，一旦项目分解，团队就需要处理跨存储库的依赖关系。

Perforce是集中式的

Helix Core – Perforce的版本控制使用集中式模型。将所有内容存储在一个地方可确保开发人员始终拥有最新版本。开发人员，无论位于何处，都将所有更改提交到中央服务器。拥有一个项目的副本会在整个企业中创建单一的事实来源。这也改善了沟通，因为其他团队成员很容易看到正在进行的工作。而正在进行的Git工作状态仅存储在本地存储库中。

集中式模型使代码协作和代码重用变得更加容易。并且它确保了可审计性和可追溯性。即使Helix Core是集中式的，它也可以通过副本服务器和代理服务器安全地支持远程站点。由于大多数操作都是在本地完成的，因此可以大大提高性能。

2.2 性能

在性能方面，当比较Git与Perforce时，团队常常会感到惊讶。

Git更快的地方

使用Git可以更快地进行本地提交，比较和合并。但是，许多开发人员Push和Pull会降低性能并降低生产率。

Perforce更快的地方

Helix Core专为速度和规模而设计。它每天可以处理数百万个事务，数十亿个文件和PB级的存储。开发人员可以快速，轻松地查看工作站上是否具有文件的最新版本。另外，它使用独占锁定处理大型二进制文件。这样可以防止团队成员的工作互相冲突。

借助Perforce Federated Architecture，远程团队可以在大型Clone/Pull/Build操作中体验本地速度性能。这可以减少使用传统Git进行的大量WAN等待。

2.3 管理大文件/二进制文件

大文件和二进制工件是开发的一部分。它们可能是构建和输入测试的结果。但是对于某些行业，例如游戏开发，它们是您整个过程的组成部分。您需要能够将艺术家和开发人员的作品结合到最终产品中。

Git提供LFS

今天，Git尝试使用Git LFS解决此问题。但是，大多数大型团队将其大型二进制资产存储在Nexus或Artifactory等工件存储库工具中。这意味着您不再拥有单一的数据来源。这些其他工具也使您的构建流程复杂化。

Perforce将所有内容存储在一个存储库中

在Helix Core中，工件与源代码和其他非代码资产一起存储。这些工件可以作为与相关源代码相同的更改列表的一部分检入。将所有内容都放在一台中央服务器中可以简化工作流程。而且您的管理员无需管理其他许可证和集成。

2.4 分支策略

Git和Perforce均提供轻量级分支，分支方式不同。

git分支

在Git中，创建分支后，您可以立即在本地新分支上开始工作。进行添加和更改后，可以提交到本地副本。但是，合并到master分支的本地副本与将更改推送到中央存储库不同。

如果在推送更改时多个开发人员正在处理同一个文件，则可能会发生合并冲突。这就是为什么在合并之前从服务器获取最新更改始终很重要的原因。但是，如果您有数百名开发人员在Git中开发项目，那么这可能会很耗时。

而且，如果您有跨存储库的依赖关系，则需要协调各个存储库之间的合并冲突。这可能很棘手。随着您的团队或存储库数量的增加，它变得越来越难。

Perforce分支

在Helix Core中，分支是在文件层次结构级别完成的。您的团队成员可以选择特定的文件进行检出并提交回存储库中。独占签出使开发人员可以了解其他人的工作。有了文件级别的细化权限，管理员可以保护他们最重要的文件。

Perforce Streams –我们的分支和合并方式– –简化了工作区的设置并有助于指导团队。开发人员可以轻松地在流（分支）之间切换，并且很容易看到更改是如何传播的。与Git一样，将更改提交到主流/分支时，仍然会发生冲突。这些通常易于管理。Helix Core的优点是可以看到正在进行的工作，并且可以提前通知潜在的合并冲突。

此外，Helix Core的可扩展性使开发人员可以通过一个动作提交可能影响多个组件的潜在大型变更列表。这可以大大减少代码依赖性问题，而且可以轻松地跟踪和管理这些更改。

2.5 为什么要使用Git

许多团队使用Git的原因很多，其中有很多。正如我们所描述的，它解决了最基本的版本控制问题。它使开发人员可以在不重复工作的情况下同时处理相同的代码。对于本地操作来说这是快速的。Git通常是大学中使用的第一个版本控制系统（VCS）开发人员。大多数开发人员都知道常用的Git命令，例如克隆，提交和推送。另外，它是免费的！

在过去的几年中，如雨后春笋般冒出了以开源软件货币化为使命的无数商业公司。GitHub，GitLab和Atlassian已使用Git完成了此任务，他们添加了不错的用户界面，代码审查工作流，多个存储库的管理功能以及与Git的管道集成。

这些Git提供商中的每一个在个人免费用户中都比付费企业客户更受欢迎。GitHub，GitLab和Atlassian并不总是为企业软件开发团队服务，实践证明，Git的体系结构很难在这种环境下进行扩展。

2.6 何时使用Perforce（Helix Core）

当您具备以下条件时，Perforce是正确的版本控制系统：

• 大型代码库。
• 非代码资产，例如二进制文件或图形。
• 代码依赖性，尤其是跨组件。
• 广泛的代码重用，例如工件。
• 大型，地理位置各异的团队。

这就是Perforce擅长的地方。这是因为我们的版本控制是为具有大型代码库和复杂开发环境的大型团队设计的。

2.7 Helix4Git

公司需要Perforce提供的可扩展的优势，现在，您可以获得这些好处-也可以使用Git。

解决这个复杂问题的方法不是决定使用Perforce还是Git。它与Helix4Git一起使用。

Helix4Git以Perforce Helix Core服务器的速度和可靠性本地存储Git存储库，该解决方案在业界是独一无二的，可支持您的DevOps演进。

您的开发人员仍然可以使用Git命令（例如merge和rebase），创建子模块，这是因为他们可以访问任何一种解决方案，而无需更改其工作流程或环境。实际上，即使您处于项目中间，也可以添加Helix4Git。您可以将自己的Git仓库本地存储在Helix Core中，后者还支持Git LFS组件。

中央的单一数据来源简化了持续集成/持续交付（CI / CD）。Helix4Git使Git更快—速度提高了80％，存储空间减少了18％。这意味着团队可以更快地获得所需的反馈。开发人员，发行经理和CI / CD团队可以将更多时间投入生活。