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