当你是唯一一个建立软件项目的开发人员时，你可以根据个人的喜好来创建和修改你的代码。当你为一个团队运作的项目贡献代码时，你需要遵循一套标准化的准则，并与其他团队成员精确协调。标准的指导方针和协调的工作努力对每个基于团队的软件开发项目的成功至关重要。
为了满足这一需求，全世界的工程团队都设计了许多开发工作流程。最近，大多数团队使用Git来版本化和管理他们的软件代码。基于Git的两个最流行的开发工作流程是基于主干的开发和基于功能的开发。Facebook、谷歌、Netflix和其他许多科技企业的团队都在使用这些工作流程。
在这篇文章中，我将讨论基于主干的开发和基于特性的开发，目的是帮助你决定哪种工作流程适合你的团队。
什么是基于主干的开发？
基于主干的开发工作流程是开发者团队中最受欢迎的开发框架之一。在这种工作流程中，只有一个分支（主干）被认为是主要的。它持有项目的可部署代码。
开发者可以直接将修改推送到主干分支，但如果一个编码活动需要更多的时间--也许是几天--他们可以从主干分支中签出一个分支，将修改移入其中，然后在开发完成后再将其合并回去。
然后，其他开发者必须根据公司的指导方针进行代码审查，然后再将签出的分支与主分支合并。签出分支的关键之处在于，它们是短暂的，最多两到三天的时间。
在一个基于主干的工作流程中，主干分支应该始终是可以生产的。错误的代码会破坏整个构建，导致复杂的开发历史。这意味着，团队应该在推送到主干分支之前彻底测试每一个代码变更。短暂的开发周期和自动化测试使团队能够识别缺陷并迅速从失败的构建中恢复，从而降低风险。
使用基于主干的工作流程需要团队中有经验丰富的开发人员。初级或没有经验的成员需要对工作流程有足够的了解，才能为项目做出贡献。
什么是基于特征的开发？
基于特性的开发工作流程--或称GitFlow--是软件工程的一种经典方法。开发单个特性是基于特性的工作流程的主要重点。它与基于主干的工作流程的主要区别之一是，它从不向主干分支推送代码变更。
在开发一个特性之前，开发者会检查出一个 "特性 "分支，并在那里进行所有的代码修改。当功能开发完成后，开发者会在主干分支上创建一个合并请求。根据公司政策，在将特性分支合并到主分支之前，可能会有一个代码审查。最重要的是，在基于特性的工作流中，开发人员绝不会直接将代码修改推送到主干分支。
基于特性的工作流的优势在于，数百名开发人员可以在任何时间内从事数百个独特的特性。他们可以分小阶段进行特性开发，这样多个合并请求就不会相互冲突。
基于功能的工作流程有利于经验不足或资历较浅的团队成员。他们可以在自己的功能上工作，而不用担心破坏生产代码。技术负责人、QA或任何开发团队成员可以测试每个合并请求的构建。
不过，管理基于功能的开发可能很棘手；尤其是当多个拉动请求被排队合并到主分支时。团队领导或高级软件工程师负责快速审查这些请求并将其与主代码合并。这种情况有时会导致冲突，使新的开发者感到沮丧，他们可能需要等待更长的时间来获得合并批准。较慢的整合也会导致较少的部署和较长的构建失败的恢复时间，所以产品创新可能会滞后。
基于主干的工作流程在你的CI/CD实践中的重要性
基于主干的工作流程的最大好处之一是它们能与现有的持续集成和持续交付（CI/CD）服务很好地整合。当你推送每个提交到主分支时，你可以运行自动测试（CI的一部分）来验证新的变化不会破坏主分支。然后，在所有测试成功终止后，你可以配置一个管道，在暂存分支上为QA团队创建部署。
根据QA团队的反馈，发布经理（负责创建新版本的人）可以通过将主分支的代码推送到发布分支来发布新版本。然后，发布经理可以将最新的版本部署（CD）到生产环境中。
这种工作流程保证了发布分支不被改变，因为每个版本都是独一无二的。如果有生产问题，高级开发人员有时可以创建一个修复程序来修补版本中的错误。
在创建一个新的版本后，通过将代码推送到主分支，继续进行下一个版本的开发工作。随着时间的推移，旧的版本变得陈旧，团队可以安全地删除相应的发布分支。
大多数团队使用持续集成来测试和构建他们的软件。基于主干的工作流程方法与CI/CD系统整合得很好。它允许快速迭代，并保持代码随时可以部署。
另一方面，基于功能的开发，有很长的开发周期和混乱的集成。评审过程会给预览新变化的时间增加大量的时间。
如何在你的项目中实施基于主干的开发
尽管基于主干的开发工作流程很适合许多应用程序，但也有例外。如果你正在做一个新的项目，要么是最小可行产品，要么是概念验证，那么基于主干的工作流程很可能是你要做的。
团队中的开发者可以定期推送修改，而不需要等待其他人来审查和合并拉动请求。唯一的要求是团队中要有一些有经验的开发人员，他们可以确保团队不把任何构建失败的修改提交到主干分支。或者，更好的是，自动化的CI/CD工具可以在推送代码前检查新代码的错误。
你的开发人员必须和你一样对使用基于主干的开发的决定充满信心。然而，在有些情况下，你和你的团队可能要考虑采用基于特性的工作流程来代替。
例如，有时你必须维护多个软件版本。在这些情况下，基于主干的工作流程可能对实施有挑战性。Linux内核是基于特性的开发的典型用例，它使用了长期存在的发布分支。在这种情况下，基于特性的工作流程是最明智的解决方案，因为用户可能需要在几年内--甚至可能是几十年内--维护每个发布的Linux内核版本。
要在你的项目中实现基于主干的开发，你需要。
- 一个像GitHub这样的Git版本控制的在线服务。
- 建立一个主（主干）分支，一个暂存分支，和一个生产分支。开发人员将他们的代码推送到主干分支，而发布经理则通过将主干分支与中转或生产分支合并来创建一个新的版本。
- 持续集成（CI）系统，在开发者提交的新变化可供发布之前对其进行测试。
- 持续部署（CD）系统来构建和部署项目到暂存或生产环境。
拥有一个强大的DevOps系统和文化对于任何实施基于干线开发的组织来说也是至关重要的。随着越来越多的客户使用你的产品，你会收到更多的错误报告和功能请求。这些通知将使你的开发人员忙碌起来，所以你需要一个系统来测试新的变化，然后再使软件准备发布。
查看Circle CI网站上的一些最佳CI/CD实践，了解关于设置自动测试和部署管道的想法。
总结
基于主干的开发工作流程和基于功能的开发工作流程都有好处和坏处。决定哪种解决方案最适合你的团队，取决于团队的集体偏好和经验，以及对团队工作流程的整体适合性。
用基于主干的工作流程开始一个项目可能是个好主意。随着你的代码库的扩大和稳定，你可以转向基于特征的工作流程。这种方法可以保护构建工作免受潜在的破坏，同时在将每个功能添加到生产软件之前对其进行彻底测试。
不管你的团队喜欢哪种开发工作流程，你都会从使用CI/CD系统来测试和构建软件中受益。了解更多关于使用Circle CI/CD来设置你项目的持续集成和部署管道。
