04架构管理之分支管理实践-一种git分支管理最佳实践

        专栏说明：针对于企业的架构管理岗位，分享架构管理岗位的职责，工作内容，指导架构师如何完成架构管理工作，完成架构师到架构管理者的转变。计划以10篇博客阐述清楚架构管理工作，专栏名称：架构管理之道

一句话导读

        对于架构管理、研发管理中，分支管理是公司研发过程中必不可少的一个实践。本文主要是根据个人及公司实践，来说明下具体的分支管理方法，这里的分支指的git仓库的代码分支。分支管理方法有很多，大家可以自行定义，只要能够完成研发协作即可。

目录

一句话导读

一、环境管理

        1.开发环境

        2.测试环境

        3.预发布环境

        4.生产环境

        5.扩展

二、分支管理

        1.feature分支

        2.develop分支

        3.release分支

        4.master分支

        5.tag

        6.hotfix分支

三、分支管理原则

---

一、环境管理

        一般公司研发都会有几个环境，如开发环境、测试环境、预发布环境、生产环境，有些公司甚至还有本地环境、验收环境、演示环境、性能测试环境等等。针对这么多的环境，我们研发中要根据公司、项目的实际情况，进行环境的管理。一般项目应该有开发环境、测试环境和生产环境。有些小项目也可能只有一个研发环境，项目结束后直接将研发环境转为生产环境。所以说研发环境的需求应该是根据实际情况来定的。

        1.开发环境

        研发人员将完成的代码发布到开发环境中，做初步的集成测试，开发环境由开发人员自行管理，代码极其不稳定，环境机器配置可以比较低。一般用dev标识

        2.测试环境

        主要提供给测试人员使用，代码经过研发环境自测完成后可以提测，代码由测试管理员管理，环境代码相对比较稳定，环境机器根据测试要求配置即可，不用太高配置。一般用test标识

        3.预发布环境

        主要提供个测试人员使用，或者做UAT验收使用，代码经过测试环境验证完成后，可以提交到预发布环境中，环境的配置和数据最好和生产一致，目的是在上生产前做最后确认，环境代码和生产保持一致。机器配置最好和生产环境一致。一般用pre标识

        4.生产环境

        代码最终交付的环境，一般部署经过测试验证、预发布验证的代码，生产环境由专人负责严格管理，一般用prod标识

        5.扩展

• 本地环境：研发人员自己本机的环境，开发人员自行管理，部分中间件、数据库等可以自建或者用开发环境中的组件。用户开发过程中的调试等工作。
• 验收环境：一般由测试人员管理，负责将已完成的功能需求代码部署上去，交由最终软件的用户进行测试或需求提出的业务部门进行验收测试，通常测试完成后即可发布生产环境，一般用UAT标识
• 演示环境：演示环境相对于生产环境而定义的，环境是给用户演示而定制的。功能基本和生产一致，用户相对较少，环境要保持相对稳定，尤其是客户需要做演示的时候。一般用demo标识
• 性能测试环境：主要是对软件的性能情况进行测试。环境应该和生产保持一致，但是一般性能测试环境是临时的，测试完成后即可下线。

二、分支管理

        分支管理的逻辑最好是和团队规模相匹配。更好的git分支管理，有助于团队的协作效率的提高和代码的管理。我们使用基于主干分支管理策略，将代码分支和环境相对应，提高代码的质量。

        1.feature分支

        研发分支，研发人员从develop分支拉取，并以feature/开头命名自己的研发分支，开发人员对于新的需求则在该分支上开发，并自行管理，对应本地环境。

        2.develop分支

        研发测试分支，研发人员可将开发好的代码合并到该分支上，在研发环境进行初步集成自测，该分支由研发人员自行管理。

        3.release分支

        测试分支，该分支为保护分支，不允许研发人员直接commit代码，研发人员可以发起feature分支合并到release分支的申请，由配置管理员进行合并，发布到测试环境进行集成测试。该分支由配置管理员管理。

        4.master分支

        生产分支，该分支为保护分支，不允许研发人员直接commit代码，只接受release分支的合并，由配置管理员负责管理，发布生产环境。

        5.tag

        版本归档标识，当发布的系统稳定后形成tag版本标识，进行归档。

        6.hotfix分支

        问题修复分支，如果生产版本发布稳定后，出现bug，可从master拉取hotfix分支，修复完成后，合并到release分支测试通过，将hotfix合并到master发布生产，形成新的tag；如果是发布过程中有bug，也可拉取hotfix分支，并提交release分支测试后走后续发布流程

具体如下图：

三、分支管理原则

        主分支保持稳定： 主分支（如 main 或 master）应该保持稳定，只有已上线的代码。禁止直接在主分支上开发。

• 特性分支：开发人员在对新功能的开发时，创建独立的特性分支。分支名可以描述功能的目标，如 feature/login。
• 修复分支：对于 bug 修复，创建修复分支，确保修复在主分支上得到合并。分支名可以描述修复的问题，如 hotfix/login-error.
• 命名规范：根据公司、团的命名习惯，使用统一的命名规范，清晰的命名方式以便团队成员理解分支用途。可以采用统一的前缀，如 feature/、hotfix/。
• 小而频繁的提交：不要在一次提交中修复两个bug。单次提交的改动越小，更便于其他开发者理解，每次提交关注一个特定的更改，这有助于追踪和回溯变更历史。
• 定期合并主分支：定期从主分支拉取最新代码，保持特性分支与主分支同步。避免分支过长时间的分离。
• 代码审查：代码在提交测试前进行代码审查，提高代码质量。
• 远程分支：及时推送特性分支到远程仓库，便于团队成员协作和代码审查。
• 删除不必要的分支：一旦特性分支完成开发或修复，及时删除不再需要的分支，保持仓库的整洁。
• 标签版本：使用标签来标识重要的版本发布，方便追踪和部署特定版本。
• 培训和文档： 对团队成员进行培训，分享分支管理的最佳实践和流程，编写分支管理指南。