使 Git 在企业中发挥作用

下载电子书，获取在企业中使用 Git 的 7 个技巧

产品发布的道路是曲折、扭曲、迂回的，绝非一帆风顺。这是因为现代产品开发日益呈现出多学科、快速迭代和地理分布的特点。艺术、设计、原型制作、制造、编程等都需要使用不同的工具，但又需要比以往任何时候都更紧密地协作。因此，成功的关键在于拥有敏捷开发者所说的“单一事实来源”。这意味着所有产品开发内容都存储在一个——而且只有一个——地方，在那里进行修订、保护和同步，即使贡献者遍布世界各地。

Git 长久以来一直深受开发者的欢迎，但要使其适用于企业，既不简单也不明显。本文旨在解释一些最突出的挑战及其变通方法，识别出现的模式，并勾勒出更好解决方案的轮廓。

文件限制

Git 在企业中面临的最大挑战，可以说源于其自身在处理大量文件或非常大的文件时存在的限制和性能问题。随着 Git 仓库的增长，其速度会变得非常缓慢且难以管理，公认的最大实用容量大致在 1-2 GB 内容之间。

这正是“Git 蔓延”现象的根源，即倾向于将本应是一个大型仓库的内容拆分成几十个、几百个甚至几千个小型仓库。管理如此多的仓库并非易事，并因此催生了各种工具（例如 git-annex）来驯服这种复杂性。

但这并非唯一的变通方法。另一种方法是将大型文件存储在仓库本身之外，使用像 Git Large File Storage 这样的扩展。其理念是在实际仓库中只存储一个小的“指针”文件，并在需要时从完全不同的系统检索大数据。

托管和安全

另一系列挑战围绕着托管如此多的仓库和保护其内容。Git 包含自己的守护进程，便于托管，但这种托管是完全开放的。它不需要任何授权，所以网络上的任何人都可以看到或做任何事情。这对于各种用例来说都很方便，但在企业中，唯一的作用就是让人心烦意乱。

其局限性源于 Git 只关注身份验证，而将授权留给文件系统。换句话说，Git 提供了可以用来确保提交由进行提交的个人进行加密签名的工具，但它没有提供任何通过常规访问控制列表或其他机制来锁定特定文件、文件夹、分支等的选项。

这些需求解释了第三方托管工具和服务的爆炸式增长，例如 GitHub、GitLab、Atlassian Stash 等——所有这些都涉及权衡。云端的免费托管通常意味着空间或隐私受限。本地防火墙后的免费本地托管通常意味着功能受限和 IT 难题。就像生活中的许多事情一样，你一分钱一分货，但即使是付费产品也无法神奇地消除底层工具的局限性。

出现了一种模式

这些只是 Git 在企业中采用所面临的一些挑战，但它们足以确立一种模式，一个常常被忽视的模式。Git 的每个局限性都迫使企业承担相应变通方法的“负担”，而这是不可避免的。

因此，不会花太长时间，这种隐喻的负担就会达到或超过版本控制系统（VCS）最初要解决的问题。存储大量文件或大文件意味着你需要拆分仓库，或者可能将大文件外部存储。安全托管的需求意味着你需要采用第三方解决方案或构建自己的解决方案。这些需求——以及对更细粒度访问控制、同步、可伸缩性、高可用性、灾难恢复等的需求——都会在很短的时间内为该方案增加更多的扩展、工具和流程。

结果有效地是另一种形式的 Git 蔓延，我们称之为“IT 蔓延”，迫使拥抱 Git 的 IT 部门学习、采用并支持其庞大生态系统中的各种元素。这大大增加了复杂性，并进一步增加了学习一个并非以其简洁性著称的工具的学习曲线。

更美好的图景

现代产品开发要求我们跨团队存储、修订、保护和同步内容。任何 VCS，如果其局限性要求你将其内容存储在外部、人为地分割内容，以及/或用大量其他工具和流程来增强系统，那么它就无法满足企业的需求。

一个更好的解决方案的形状应该已经很清楚了。它应该允许你存储任意数量的任何大小和类型的文件的内容。它应该能够轻松修订这些内容，并在多个团队之间进行同步，无论他们身在何处。它应该在托管配置上具有灵活性，但最好能提供集中式管理的好处，使其易于通过细粒度的访问控制来定义组、用户及其权限。此外，它当然应该足够开放和灵活，以适应不同的工作流程，尽可能地不干扰，让艺术家、设计师、程序员和其他贡献者能够使用他们喜欢的工具来开发内容。

Git 本身只勾勒出该形状的一小部分轮廓。添加多个扩展和工具可以使其更多地显现出来。但对于企业来说，总有一天，变通方法——及其额外的需求、复杂性和局限性——会带来与它们解决的问题一样多的问题。这就是你意识到你一直需要的是一个企业级解决方案的时候。

更好的解决方案

相比之下，Perforce Helix 满足企业需求，无需强制您接受大量不受支持的扩展，也无需耗费宝贵的开发周期来构建自制工具来弥补不足。恰恰相反，它直接填补了我们一直以来描绘的图景，而且由一个以提供优质支持而闻名的单一供应商提供，所有这些都可以通过原生的 Git 和开发人员熟悉并喜爱的全套 Git 工具生态系统来获得。

例如，Helix 可以处理除源代码之外的任何数量的数字资产，以及任何类型的数据，无论其文件大小如何。Helix 支持数万个并发用户，每天处理数百万笔交易。凭借其联邦架构、集群和高可用性选项，它可以自动将所有内容同步到世界各地的远程团队，并在硬件出现故障时让用户继续工作。这之所以成为可能，是因为 Helix 版本引擎经过了几十年的精心开发和调优，所有这些都旨在实现最大的可伸缩性、性能和可靠性。

更重要的是，Helix 不仅仅是一个出色的 Git 解决方案，适合开发人员；它是一个更广泛的平台，面向企业中的所有利益相关者。它提供自己的原生分布式版本控制系统（DVCS）功能、直至文件级别的细粒度安全、无法合并的数字资产锁定功能、协作和审查、对完整生产管线的分析和洞察等等。Helix Threat Detection 组件甚至利用先进的行为分析技术，在您的知识产权外流之前检测、分类、评估和报告潜在风险。

结论

选择合适的 VCS 都是为了赋予您的团队更快速、更经济地构建更好产品的能力。Git 可能是免费的，但让 Git 在企业中发挥作用并非免费，尤其是在生产力损失、各种变通方法的复杂性和负担以及学习其和相关工具/扩展的学习曲线方面，都存在隐藏成本。组织在做出最终决定之前，应考虑所有相关因素。简而言之，如果您的 VCS 不能轻松且内在解决它所需的所有原因，那么它显然不是一个理想的解决方案。你应该另寻他处。