为什么要为您的组织使用 Git
从集中式版本控制系统切换到 Git 会改变开发团队创建软件的方式。而且，如果您是一家依赖其软件来开发任务关键型应用的公司，那么改变您的开发工作流程会影响你的整个业务。
Git 适合开发人员
功能分支工作流
Git 的最大优势之一是其分支功能。与集中式版本控制系统不同，Git 分支便宜且易于合并。这简化了受许多 Git 用户欢迎的功能分支工作流程。
相关资料
Git 速查表
查看解决方案
了解 Bitbucket Cloud 的 Git
分布式开发
在 SVN 中，每个开发人员都会获得一个指向单个中央存储库的工作副本。但是，Git 是一个分布式版本控制系统。不是工作副本，而是每个开发人员都有自己的本地存储库，里面有完整的提交历史记录。
拥有完整的本地历史记录可以让 Git 变得更快，因为这意味着您不需要网络连接即可创建提交、检查文件的先前版本或在提交之间执行比对。
分布式开发还可以更轻松地扩展您的工程团队。如果有人破坏了 SVN 中的生产分支，则其他开发人员在修复之前无法添加变更。对于 Git 来说，这种障碍是不存在的。每个人都可以继续在自己的本地存储库中作业。
而且，与功能分支类似，分布式开发创造了更可靠的环境。即使开发者删除了自己的存储库，他们也可以简单地克隆别人的存储库然后重新开始。
拉取请求
Bitbucket 等许多源代码管理工具都通过拉取请求增强了 Git 的核心功能。拉取请求是一种要求其他开发人员将您的一个分支合并到他们存储库中的方式。这不仅使项目主管更容易跟踪变更，还可以让开发人员在将其与代码库其余部分集成之前围绕他们的工作展开讨论。
由于它们本质上是附加到功能分支的评论话题，因此拉取请求的用途非常广泛。当开发人员遇到棘手问题时，他们可以提出拉取请求，向团队其他成员寻求帮助。或者，初级开发人员可以通过将拉取请求视为正式的代码审查来确信他们不会破坏整个项目。
社区
在许多圈子里，Git 已成为新项目的预期版本控制系统。如果您的团队正在使用 Git，您很可能不必对新员工进行工作流程培训，因为他们已经熟悉了分布式开发。
此外，Git 在开源项目中非常受欢迎。这意味着可以轻松利用第三方库并鼓励其他人克隆您自己的开源代码。
更快的发布周期
功能分支、分布式开发、拉取请求和稳定社区的最终结果是更快的发布周期。这些功能促进了敏捷的工作流程，鼓励开发人员更频繁地共享较小的变更。反过来，与集中式版本控制系统常见的单一版本相比，变更可以更快地推送到部署管道中。
正如您所预料的那样，Git 在持续集成和持续交付环境中运行得很好。Git 钩子允许您在存储库内发生某些事件时运行脚本，这使您可以自动部署到您想要的内容。您甚至可以从特定分支构建代码或将代码部署到不同的服务器。
例如，您可能需要配置 Git，以便在有人将拉取请求合并到测试服务器时，将最新的提交从开发分支部署到测试服务器。将这种构建自动化与同行评审相结合，意味着在代码从开发到暂存再到生产的过程中，您可以极大地放心。
Git 适合营销人员
要了解切换到 Git 会如何影响您公司的营销活动，假设您的开发团队计划在接下来几周内完成三项不同的变更：
- 整个团队正在完成一项他们在过去 6 个月中一直在开发的颠覆性功能。
- Mary 正在实施一项规模较小、无关的功能，该功能仅影响现有客户。
- Rick 正在对用户界面进行一些急需的更新。
如果您使用的是依赖集中式 VCS 的传统开发工作流程，那么所有这些变更可能会汇总到一个版本中。营销人员只能发布一个主要关注颠覆性功能的公告，而另外两个更新的营销潜力实际上被忽略了。
Git 促进了更短的开发周期，因此可以更轻松地将它们划分为单独的版本。这使营销人员可以更频繁地谈论更多话题。在上述场景中，营销人员可以围绕每个功能构建三个广告系列，从而针对非常具体的细分市场。
例如，他们可能会为颠覆性功能准备大量的公关推广，为 Mary 的功能准备企业博客文章和新闻通讯简介，以及一些关于 Rick 基本用户体验理论的客座帖子，以便发送给外部设计博客。所有这些活动都可以与单独的版本同步。
Git 适合产品管理人员
Git 在产品管理方面的好处与营销的好处大致相同。更频繁的发布意味着更频繁的客户反馈以及针对反馈更快的更新速度。您可以像开发人员编写代码一样快速将解决方案推送给客户，而不必等待 8 周后的新版本。
当优先级发生变化时，功能分支工作流程还提供了灵活性。例如，如果您已经进入发布周期的一半，您想推迟一项功能来代替另一项时间紧迫的功能，那就没问题了。最初的功能可以在自己的分支中保留，直到工程部门有时间回头处理。
同样的功能使您可以轻松地将创新项目、beta 测试和快速原型作为独立代码库进行管理。
Git 适合设计人员
功能分支适合于快速原型开发。无论您的 UX/UI 设计师是想实现全新的用户流还是干脆替换一些图标，查看新分支都会为他们提供一个沙盒环境供他们操作。这使设计人员可以看到他们所做的变更在产品的真实工作副本中将如何显示，而不会威胁破坏现有功能。
像这样封装用户界面变更可以轻松地向其他利益相关者提供更新。例如，如果工程总监想看看设计团队在做什么，他们要做的就是告诉主管去相应的分支查阅。
拉取请求更进一步，为感兴趣的各方提供了讨论新界面的正式场所。设计人员可以进行任何必要的变更，生成的提交将显示在拉取请求中。这会邀请所有人参与迭代流程。
也许使用分支进行原型设计的最好之处在于，将变更合并到生产环境和放弃变更一样容易。随便哪个操作都很轻松。这鼓励设计人员和用户界面开发人员进行实验，同时确保只有最好的想法才能传达给客户。
Git 适合客户支持人员
客户支持和客户成功对更新的看法通常与产品经理不同。客户通常是在遇到某种问题时才会打电话给他们。如果该问题是由您公司的软件引起的，则需要尽快推出错误修复。
Git 简化的开发周期避免了将错误修复推迟到下一个单一版本发布。开发人员可以修补问题并将其直接推送到生产环境中。更快的修复意味着更满意的客户和更少的重复支持工作单。您的客户支持团队可以开始回复“我们已经修复了这个问题！”，而不是一直重复“对不起，我们马上解决”。
Git 适合人力资源人员
在某种程度上，您的软件开发工作流程决定了您雇佣的员工。聘请熟悉您的技术和工作流程的工程师总是有帮助的，但是使用 Git 还有其他好处。
员工会被提供职业发展机会的公司所吸引，了解如何在大型和小型组织中利用 Git 对任何程序员来说都是福音。选择 Git 作为版本控制系统，您就是在吸引有远见的开发人员。
Git 适合管理预算的所有人员
Git 的关键在于效率。对于开发人员来说，它消除了所有问题，从浪费在网络连接上传递提交的时间到在集中式版本控制系统中集成变更所需的工时。它甚至可以为初级开发人员提供安全的工作环境，从而更好地利用他们。所有这些都会影响您的工程部门的利润。
但是，不要忘记，这些效率还会扩展到您的开发团队之外。防止营销人员将精力投入到不受欢迎的次要功能中，允许设计人员以低成本在实际产品上测试新接口，使您可以立即对客户的投诉做出反应。
保持敏捷就是要尽快找出行之有效的方法，放大成功的努力，淘汰不成功的努力。Git 可确保每个部门更高效地完成工作，从而为您的所有业务活动提供助力。
分享此文章
下一主题
推荐阅读
将这些资源加入书签，以了解 DevOps 团队的类型，或获取 Atlassian 关于 DevOps 的持续更新。
Bitbucket 博客
DevOps 学习路径
