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