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