代码分支管理规则： ​

1. 新功能开发（bug修改） 从master上切出一个新的功能（bug修复）分支
2. 开发人员应该使用自己的个人分支进行开发，开发后合并到功能分支
3. 开发完成由开发人员合到release进行测试
4. 测试完毕，上正式：
   1. 需要更新的开发人员，在研发云提起合并请求，管理员审核通过后合并
   2. 管理员直接把功能（bug修复）分支合并到master上后，推送至云端
   3. 开发人员发布部署需求至运维人员处，运维人员进行更新
5. 关于提交信息，请参考之前制定的git 提交规范
6. 关于git pull会产生多余merge信息的说明： 因为git pull命令会产生两步操作git fetch和git merge，git pull默认会拉取远程分支并尝试合并，如果合并成功，会生成一个合并提交，增加一条记录 解决方法：
   1. 使用命令行设置pull.rebase 默认为true
      1. 全局所有git仓库均设置为true：==git config --global pull.rebase true==
      2. 仅当前git仓库设置为true：（仓库文件夹路径下执行）==git config pull.rebase true==
   2. 使用命令行，每次拉取代码为git pull命令加额外参数：==git pull --rebase==
   3. 使用Git工具时，可能需要找对应平台设置git pull --rebase的配置
   4. 提交前，将本地的提交先使用git stash
7. 关于Tag（版本）的发布（一般由管理员发布）
   1. 每个正式版本都应该是一个Tag
   2. Tag的格式为 主版本号.次版本号.更新日期.版本次序
   3. 每个版本的信息应该详细记录每次更新的所有主要内容

   例子： 2025年03月09日更新了版本，那么我们的版本号应该是1.1.20250309； 当天又更新了第二个版本，版本号则为1.1.20250309-1

#电信