嵌入式git分支管理策略
一、前言
本文介绍一下git代码代码维护策略，以我待的嵌入式行业为例，其他行业也是类似的策略。介绍项目代码常见的分支介绍和维护策略，比如常见的分支master、release、tag分支(hofix)、dev(feature开发) 分支。
二、常规的分支管理策略(4分支)
- 常用的四个分支：
- master分支（上图main分支）：主干分支，功能最全，相对稳定，开封分支feature分支功能测试稳定后才能合回主干，主干合并集成多个feature的集合，定期集成测试，拉出release分支用于软件发布。
- feature_n 分支：开发分支，改动很大的功能，或者新机型等，回影响主干机型软件发布时，此时拉出开发分支feature做QA测试，QA测试完成稳定之后合并回主干分支。公司多个功能同时开发，feature分支会有多个。小的功能点开发可以直接在master分支进行，不必拉分支处理。
- release分支：master分支上定期QA集成测试通过之后，拉出release分支，用于软件发布，此分支稳定，仅仅用于修复市场反馈问题，以及衍生机型的软件发布工作。嵌入式项目，大部分公司都是机海战术，衍生机型会很多，先对一个机型在master分支提测稳定后，再拉出新的release分支进行切换，其他衍生机型在新的release分支QA测试，然后发布。在切换到新的release分支后，旧的release分支要弃用。不断的拉出release分支，然后合并主干，再拉release分支，合并主干，不断的回滚发布。若旧release分支不弃用，会增加分支同步的工作，后续软件发布还要同步旧release分支的提交，所以建议定期收集分支使用情况。杜绝使用弃用分支的情况。
- hotfix分支：紧急修复某个市场反馈问题等拉出的分支，通常基于软件对应的tag分支，只针对修改的代码库拉出分支，其他库使用tag。短期使用后，迅速合并回release分支，后续QA发布仍然使用release分支。
这几个分支的修改量大小，以及稳定性如下表：
| 分支 | 作用 | 修改量 | 稳定性 |
|---|---|---|---|
| feature | 功能开发 | 大 | 不稳定 |
| master | 主干集成 | 较大 | 较稳定 |
| release | 软件发布QA提测 | 小 | 稳定 |
| hotfix | 紧急修复 | 非常小 | 非常稳定 |
- tips：
1）每轮发布软件要打上tag，并创建对应的tag repo xml。
2）release分支是以某个发布固件tag为基础拉出的分支。
三、精简的分支管理策略(2分支)
上述4个分支是从整个公司层面维护的分支情况，但是对于某个机型的开发分支，其实又分为dev分支和release分支(tag分支)，开发分支和发布分支，dev分支就是该机型的主干分支。常用的是如下两个分支：
| 分支 | 机型软件情况 |
|---|---|
| dev | 该机型开发主干分支 |
| release | 该机型软件发布tag分支 |
dev用户平时开发工作，release分支是定期QA测试后的发布分支（tag分支），使用此分支进行即可。常规使用这两个分支即可，hotfix分支一般情况下不需要，release分支也是dev分支需要定期回归到公司的主干分支。release的tag分支也是采用回滚的方式，定期回归dev分支进行和QA提测验证，合并dev分支的新功能。
四、tips
画上述git分支图可以使用mermaid语法，但是typora无法渲染，可以使用如下网站在线画图，语法如下：
中文mermaid网站
---
title: Git分支维护策略
---
gitGraphcommitcommitbranch "feature_n"checkout "feature_n"commitcommitcheckout maincommitbranch "release_1"checkout "release_1"commitcommitbranch "hotfix_1"commitcheckout "release_1"merge "hotfix_1"checkout mainmerge "feature_n"commitmerge "release_1"commitcommitbranch "release_2"checkout "release_2"commitcommitbranch "hotfix_2"commitcheckout "release_2"merge "hotfix_2"checkout maincommitcommitmerge "release_2"