一旦涉及版本控制系统，Git实际上代表敏捷开发的水平。Git作为一款强大的开源系统，有较强的灵活性，可以按需匹配任何开发团队的工作流程。而这种分布式相比较集中式来说，自然赋予系统更好的性能特征，且允许开发人员在本地自由实验，在他们修改到自己认为没有问题时再发布到团队。
除了灵活性和分布式等优点外，Git的主要职能是支持和强化敏捷开发。将Git视为敏捷开发的一部分，与单片发布和集中版本控制系统相比，所有变更可以更快部署。
专家提示： Git是分布式版本控制系统(DVCS)。与CVS或Subversion (SVN)等工具不同，Git允许开发人员在团队资源库中创建个人独有的分支，并与主代码库并行存储。这些自创副本被称为fork。fork上的工作完成后，开发人员可以很轻松地将更改上传至主代码库。
方法一：将开发任务视为Git的分支
在产品功能细化并添加至产品路线图，开发团队做好开工准备后，Git开始发挥作用。但在正式开发之前，团队需要有一个敏捷功能开发速成课：产品、设计、质保(QA)、研发要开一个功能启动会就具体的功能、项目范围以及为了确保完成这些功能该被分解成什么样的任务等方面达成共识。在这些被称为用户故事的任务拆解完成之后，任务会分配给各个开发人员。
Git也是在这个时候参与到我们的敏捷开发流程中。在Worktile，我们会为每个独立的任务创建一个新的分支，无论是新的功能，BUG修复还是对现有代码的调整，每次代码的更改都会创建新的分支作为开发分支，等我们把功能完全做完之后，会提交Pull Request 到develop分支或者其他我们稳定的分支中，有管理员或者其他有合并权限的成员进行代码 Review，之后合并代码。 分支的应用使任务变得直观易懂，同时允许团队在一个中央代码库内轻松协作。开发人员一旦创建了分支，就意味着他们实际上拥有独立于中央代码库之外的个人代码库。
对敏捷团队而言，将功能拆分为用户故事后创建相应的分支，意味着开发团队的成员可以单独处理各自的任务，基于相同的代码库在不同的仓储下工作。开发工作量并未因此增加，因为开发人员能够更专注在与主仓储分开的小块任务，这样也避免因为存在过多依赖关系而减缓开发进程。
专家提示： 除了设置任务分支之外，还可以设置其他类型的Git分支，且它们之间可以兼容并存。例如，我们可以为单个版本的发布设置不同的分支，这样可以让开发人员为特定版本进一步制定稳定和强化的工作计划，而同时也不会影响到其他开发人员开发未来的版本。
创建单个版本发布的分支之后，需要定期将其融合到主分支任务中，确保所涉及的功能都能兼容到未来的版本中并发挥作用。为了最大限度地减少积压，所创建的单个版本发布的分支最好尽可能接近计划发布日期。
方法二：充分利用多分支可单独测试的优势
分支一旦被认为已经完成并可以进行代码review后，Git就开始在敏捷开发流程中扮演另外一个关键角色：测试。成功的敏捷团队会进行代码review并进行自动化测试(持续集成)。为了更好地完成代码review和测试工作，开发人员可以直接通知团队其他成员该分支已经完成可以review，然后提交Pull Request。简单来讲，Pull Request就是请求其他开发人员将你已经做好可以进行测试的分支合并到主分支上。
如果工具使用得当，持续集成服务器就可以在合并之前创建并检测你提交的Pull Request。这样做能确保合并分支不会出现问题。通常情况下，还能让我们更轻松地重新定位Bug修复和冲突，因为在各分支之间存在分歧时，Git能够区分各分支与主代码库之间的差异。
专家提示： 一个长期运行且未合并到主分支的分支，可能会影响团队的敏捷性和迭代能力。如果存在一个长期运行的分支，就意味着实际上存在两个不同版本的代码库，而这将直接带来更多的bug修复工作和冲突。最好的解决方式是设定短期的分支，可以通过将用户故事拆分为较小的任务、更为细致的sprint规划以及尽早合并代码作为隐性特征(dark features)等这些方式来实现。
方法三：Git确保敏捷开发的透明度和质量
Git/敏捷故事通常与效率、测试、自动化和整体敏捷性有关。将分支合并到主分支后，敏捷的工作流程就完成了。同样，通过提交Pull Request将代码合并后，意味着在代码完成的同时，所有文档中的工作也已经完成，团队其他成员已经停止代码活动，且已经可以进行发布。这使得敏捷团队可以快速而自信地进行频繁的发布：这也是成功敏捷团队的一个标志。
专家提示： 定期发布是敏捷开发的关键。要让Git适应敏捷工作流程，就要确保主分支一直是健康畅通的。这意味着，如果某个功能尚未做好，就可以等到下次再发版。如果团队想尝试较短的发版周期，也是可以的。
