对于敏捷和 DevOps 软件开发团队来说，Git 是事实上的版本控制系统，也是 DevOps 工具链的重要组成部分。这个得到良好支持的开源项目足够灵活，可以支持一系列适合任何给定软件团队需求的工作流。它的分布式特性（而不是集中式）赋予了它卓越的性能特征，并允许开发人员自由地在本地进行实验，只有在准备好分发给团队时才发布他们的更改。
除了灵活性和分发性的优势，Git 还有一些关键功能可以支持和增强敏捷和 DevOps 开发团队。将 Git 视为敏捷和 DevOps 开发的一个组件：与使用整体版本和集中式版本控制系统相比，更改可以更快地叠加到部署管道中。Git 的工作方式与您的敏捷团队和 DevOps 团队的工作方式相同（并且应该努力工作）。
提示 1：开始将任务视为 Git 分支
在功能充实、添加到产品路线图以及开发团队准备就绪后，Git 才开始发挥作用。但退后一步，这里是敏捷功能开发的快速速成班：产品、设计、质量保证 (QA) 和工程师举行功能启动会议，就功能是什么（考虑需求）、项目范围以及该功能需要分解成哪些任务才能完成达成共识。然后，这些任务（也称为用户故事）将分配给单个开发人员。
此时，Git 开始适应您的敏捷工作流。在 Atlassian，我们为每个事务都创建了一个新分支。无论是新功能、错误修复还是对某些现有代码的微小改进，每次代码更改都有自己的分支。
分支很简单，允许团队在一个中央代码库中轻松协作。当开发人员创建分支时，他们实际上有自己的隔离版本的代码库，可以在其中进行更改。对于敏捷团队来说，这意味着通过将功能分解为用户故事，然后分支，开发团队能够单独处理任务，并在不同的存储库中更高效地处理相同的代码；工作不会加倍，因为个人能够专注于与主存储库分开的存储库中的小部分工作，没有那么多依赖关系来减慢开发过程。
除了任务分支外，还有其他类型的 Git 分支，它们并不相互排斥。例如，您可以为发布创建分支。这使开发人员可以稳定和强化特定版本的计划工作，而不会阻碍其他正在开发未来版本的开发人员。
创建发布分支后，您需要定期将其合并到主分支中，以确保您的功能工作能够在将来的版本中使用。为了最大限度地减少开销，最好在尽可能接近预定发布日期的时间创建发布分支。
提示 2：多个分支可以单独测试，因此请充分利用
一旦分支被认为已经完成并准备好进行代码审查，Git 将在敏捷开发工作流中扮演另一个关键角色：测试。成功的敏捷团队和 DevOps 团队练习代码审查并设置自动测试（持续集成或持续交付）。为了帮助代码审查和测试，开发人员可以轻松地通知团队的其他成员，分支工作已准备就绪，需要通过拉取请求进行审核。更简单地说，拉取请求是一种让其他开发者将您的一个分支合并到主分支并准备好进行测试的方法。
借助正确的工具，持续集成服务器可以在合并拉取请求之前进行构建和测试。这使您确信合并不会造成问题。这种信心使得重新定位错误修复和冲突变得更加容易，因为自分支存在分歧开始，Git 知道分支和主代码库之间的区别。
长时间运行的功能分支没有合并到主分支可能会损害您的敏捷和迭代能力。如果您有一个长时间运行的功能分支，请记住，您的代码库实际上有两个不同的版本，这将导致更多的错误修复和冲突。但最好的解决方案是拥有短暂的功能分支。这可以通过将用户故事分解为较小的任务、仔细的冲刺规划以及尽早合并代码以作为模糊功能发布来实现。
提示 3：Git 为敏捷开发提供透明度和质量
Git/敏捷的故事讲述的是效率、测试、自动化和整体敏捷性。将分支合并到主分支后，您的敏捷工作流就完成了。同样，通过拉取请求合并代码意味着，当代码完成后，您可以通过文档清楚地知道工作已完成，其他团队成员已经签署了代码，并且已经准备好发布。这使敏捷团队能够快速前进，并充满信心地经常发布：这是一支优秀的敏捷团队的标志。
采用常规发布节奏是敏捷开发的关键。为了让 Git 适用于您的敏捷工作流，您需要确保您的主工作流始终处于完成状态。这意味着，如果某个功能尚未准备就绪，则需要等待下一个版本。如果您采用的是更短的发布周期，这不应该也不会有什么大不了的。
