✍️本文译者： P2Tree
©️ 本文演绎自 Atlassian 编写的 Why Git for your organization。页面上所有内容采用知识共享-署名（CC BY 2.5 AU）许可协议。
从集中式版本控制系统切换到Git的决定，将会改变你所在开发团队创造软件的方式。如果你所在公司是一家依靠软件来执行关键任务应用的公司，改变开发工作流程会影响公司的整个业务进展。
在这篇文章中，我们将会讨论Git对公司各个方面的有益帮助，从开发团队到市场团队，以及所有其他的一切。这篇文章结束时，你就会清晰的发现Git不只适用于敏捷的软件开发工作，它也适用于敏捷的商业活动。
其中最大的一个优点是Git支持分支特性（Feature Branch），不同于集中版本控制系统，Git的分支是很容易使用和合并的。这个特性分支工作流的开发机制在Git用户中非常流行。
特性分支为代码库的每一次更改提供了一个隔离的环境。当开发者希望开始工作时，不管工作内容有多复杂，他们都可以创建一个新的分支。这能确保在Master分支上总是保持具有生产质量的代码。
使用特性分支进行开发相比于直接在生产代码上开发更可靠保险，同时它还提供了组织上的好处。这可以保证开发工作的内容与敏捷工作清单（agile backlog）保持相同的操作粒度（译著：大意应该是工作内容中相同粒度的工作可以建立特性分支来完成），例如，你可以实现一种策略，使得在Jira上的每一个提交都对应到相应的特性分支。
在SVN中，每一个开发者都会获取一份开发的副本，这个副本内容对应到单一的集中仓库中的某个节点。而Git是一个分布式的版本控制系统，它并不是复制某个节点的副本，取而代之的是，每个开发者都有一个属于他们自己的本地仓库，具有完整的提交历史信息。
本地拥有完整的提交历史可以使Git使用起来更快捷，因为你不需要网络连接就可以创建提交、查看某个文件之前的历史版本信息或者是比较不同提交之间的变更差异。
分布式的开发也可以更易于扩展你的工程团队。在SVN上，如果某个开发者弄坏了产品分支，其他开发者将不能继续提交他们的变更，只能等待问题修复。在Git上，这样的问题是不存在的，每一个人可以继续在他们自己的本地仓库中进行工作。
同时，与特性分支类似，分布式开发创建了一套更可靠的开发环境。即使一个开发者破坏了他自己的本地仓库，他也可以轻松的克隆其他人的仓库并重新开始工作。
很多源代码管理工具设计了pull requests的功能来扩展Git核心功能。pull requests可以允许你请求其他开发者合并你的分支到他们的仓库，这不但使得在工程中追踪变更更为简单，也可以促进开发者在合并工作之前做充分的讨论。
由于pull requests本质上是附加到特性分支上评注功能，所以它的用途非常广泛。当一个开发者遇到比较困难的问题时，他们可以通过创建一个pull requests来向团队的其他成员寻求帮助。同时，初级开发者也可以确信自己的pull requests不会作为正式的code review，进而不会破坏整个项目进展。
在许多领域，Git已经成为新项目的预期版本控制系统。如果你的团队使用Git，很可能你不需要在工作中去培训新员工如何使用Git，因为他们已经很熟悉分布式开发的技术。
另外，Git在开源项目中非常流行，这意味着使用第三方库变得很容易，并且更易于鼓励其他开发者去fork你自己的开源代码。
前边提到的特性分支、分布式开发、pull requests、以及稳定的社区，他们最终的努力结果是更快的发布周期。这些功能有助于实现敏捷的工作流程，鼓励开发者更频繁的共享较小的更改。反过来，和集中式版本控制系统中常见的整体发布相比，Git的部署发布流程可以更迅速。
正如你所期待的，Git非常易于在持续集成和持续交付环境下使用。Git hooks功能允许在仓库中确定的事件发生时触发运行特定的脚本，这样可以实现自动部署的工作，甚至可以从特定的分支上构建并部署到不同的服务器上。
比如，通过配置Git，可以实现每当有人将pull request合并到开发服务器时，自动部署开发分支上最新的版本代码到一个测试服务器上。将这种自动化构建和代码review相结合，你将更有信心将开发内容过渡到成熟产品中。
为了能顺利理解Git如何影响公司的市场活动，可以想象开发团队在接下来几周内有3个独立的日程需要完成，分别是：
- 整个团队都正在努力完成过去6个月以来的游戏更新特性；
- Mary正在实现一个小的，不太相关的特性，仅仅会影响部分用户；
- Rick正在实现一些针对用户接口上必要的更新内容；
如果公司使用的是传统的开发工作流程，依赖于一个集中式的版本控制系统，所有这些改变都需要在同一个版本上发生。市场营销只能发布一个注重于游戏更新特性的公告，故而容易忽略掉其他两个更新的市场潜力。
Git拥有更短的开发周期机制，它可以很容易的将这些独立的发布版分开发布。这可以让营销人员可以充分的描述发布版本的细节。在上边这个场景中，市场营销可以针对三个功能建立独立的活动，从而针对更为特定的细分市场。
例如，他们可以准备一个大的PR来推送游戏更新特性，然后将Mary的特性公布到公司的博客上或者是新闻简报上，再将Rick的用户接口的设计内容发布到外部的设计博客上。所有这些活动可以同时在独立的发布流程中进行。
Git在产品经理这边的优势和对于营销人员的基本类似。更为频繁的版本发布意味着更加频繁的用户反馈，从而能更为迅速的针对反馈结果做出更新响应。可以在开发者完成代码工作的同时，立即向用户反馈结果，而不是等待8周后下一个版本更新。
当有更为优先的变更时，特征分支的工作流同样可以提供更为灵活的解决方案。比如说，如果正在版本发布中途，需要推迟一项功能并替代另一项更为紧迫的功能时，Git能够完美解决。最初的特性可以暂时先放在它自己的分支上，直到工程师有时间继续处理它。
这个功能同样可以用于易于管理创新性的项目、内部测试版软件以及需要快速迭代原型的独立代码库。
特性分支可以快速迭代原型。无论你的UX/UI设计师是想实现一个全新的用户交互过程，还是简单替换一些图标，通过检出一个新的分支就可以得到一个可操作的安全的沙盒环境，从而，设计师可以在一个完整的工作副本上查看他们的改动效果，同时还不存在可能破坏已有设计的风险。
这样的方式修改用户界面，可以轻松的向其他成员展示更新效果。比如说，如果工程总监希望看一下设计团队正在干什么，那么只需要去查看相关的设计分支就可以了。
Pull Request能够更进一步的提供一个正式的途径来让相关人员参与到新界面设计效果的讨论中。设计师们可以提交相关的设计变更，这些提交都会以commit的形式展示在pull request列表中，进而让所有相关的人员能够参与到设计迭代的过程中。
优秀的分支结构应该易于合并到产品主线中，就像将它抛弃一样便捷。这一点Git同样表现优秀，这将有利于设计师和UI开发工程师在做一些实验性的设计时，能够确保只将最佳的设计结果展示给用户。
客户支持和客户认同（译注：原文为customer success，意指通过我们的服务或产品让客户对结果满意）工作与产品经理面对的情况不同。当客户联系他们时，通常他们一定会遇到一些问题。如果这些问题是由公司的软件导致的，那么修复问题的工作就应该尽快开始。
Git灵活的开发周期可以避免了将问题修复的工作推迟到发布下一个大的版本之后。开发者可以提交一个补丁并直接推送到生产线上。快速修复bug意味着可以让客户满意以及让客户不必反馈重复的问题。这样，你的客户支持团队就可以很快就能给客户回复说“问题已经修复了”，而不是回复用户“不好意思，我们正在修复中”。
能够确定的说，你的软件开发模式决定着你要雇佣的人，因为你总是希望去雇佣能够熟悉你的技术和工作流程的工程师，Git除了满足这样的要求外，它还有其他优势。
公司能够通过提供职业发展机会来吸引应聘者，并且对于任何程序员来说，都会乐于去了解在大型或小型组织中如何使用Git。选择把Git作为公司的版本控制系统，你便能够吸引更多有远见的开发者。
Git是高效的。对于开发者，相比于集中式的版本控制系统，它能够消除通过网络提交变更所浪费的时间。也更有利于新手开发者使用，因为它提供了一个安全的工作环境。所有这些都将会影响你的开发部门的运行。
但是，不要忘记这些高效性对于非技术团队以外的团队也同样奏效。市场团队可以防止对不受欢迎的功能投入过多精力；设计团队可以用很小的开销即可在真实的产品上进行新接口的试验；客户支持团队又能够更快的反馈客户的问题。
敏捷开发意味着需要做到如何尽快的完成工作，放大成功的效果，减小失败的影响。Git能确保每个部门的工作都更高效率，从而让你的商业活动进展更快。