取综各产品研发分支开发

弘连各产品研发开发采用Git仓库管理。版本号取名规范等都是统一形式:

${主版本号}.${子版本号}.${修正版本号}.${编译版本号}
Major_Version_Number.Minor_Version_Number.Revision_Number.Build_Number 示例： 1.2.1.xxx 4.6.7.xxx 3.5.4.xxx

现阶段分支管理没有好的秩序，各版本号发布随意，未有统一约定：

• 完成某个新功能未设置tag，没有更清晰描述功能节点；
• 开发某个新功能时，直接在原分支改，尔后才切换；
• 当前分支修复某个功能的bug时，没有pick到原功能集(原功能有bug，只能升级，没有修复的更新版本)；
• dev分支管理松散

版本号约定

Major: 具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。 \
Minor: 如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。 \
Revision: 名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。 \
Build: 内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。

版本号规则

主版本号修改: 当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。 \
子版本号修改: 当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。 \
阶段版本号修改: 一般是 Bug 修复或是一些小的需求小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。 \
Build: 用于记录和区分每次的[编译/代码录入]递增。

正确步骤

• $git init // 项目开始
• $git checkout -b dev // 项目切到开发分支
• // dev分支，同组成员有pull，没有push权限；项目经理有pull/push 权限
• // 项目开始，fork项目，或者书写组内共识、开发文档等；
• $touch README.md && git add . && git commit -m "doc 新增README" // commit 开头指明目的: fix feat chore doc style test refactor
• $git checkout -b dev-1.0 // 项目开始1.0（此时组内讨论开发迭代会）
• $git checkout -b dev-1.0.x // 项目开始新功能开发，不断增加Revision/Build号: dev-1.0.x.xxx
• $git merge/rebase dev-1.0.x dev-1.0 // 合并开发分支至功能版本节点
• $git merge/rebase dev-1.0 dev // 合并功能节点至开发节点
• // 开发下一个迭代
• $git checkout -b dev-1.1 // 项目开始1.1（此时组内讨论开发迭代会）
• $git checkout -b dev-1.1.0 // 项目开发新功能，不断增加build号: dev-1.1.x.xxx
• $echo "new text" >> new.txt // 修改编辑
• $git add . && git commit -m "feat 修改new" // 新功能分支改了dev-1.0 的bug, 这时需要同步该修复
• $git checkout dev-1.0.x && git cherry-pick ${修改commit} // 使用cherry-pick 将修改commit 拿回到dev-1.0.x中，测试成功后，合并回dev-1.0中