Boot+Cloud项目学习：macrozheng.com
2年前，记忆犹新啊！别的部门招聘人多于HC，送过来我们组一个研发“T6大佬”，这哥们第一次接需求，就直接在 test 分支写自己的需求代码。等到测试完，这哥们要把 test 分支合并到 master 上线时，全县的鸡鸭鹅狗都慌了！再强大的规范，也干不过有人偷偷捣乱。
test 分支是全组40来个研发，各自需求分支代码合并过来测试的分支，有很多都是在测试中的，还不能一起上线！所以，那个夜晚，40来个研发，一起配合“T6大佬”往出拆代码！拆完之后还要重新进行测试，就这样才保证了第二天可以上线。否则又要等下一周的上线日了。
做程序员👨🏻💻能实现业务逻辑写代码虽然占比很大，但绝对不是说程序员就只是写代码。还要清楚的知道必要的研发规范，同时熟练的使用相关从开发到上线的一些列工具。并且具有风险意识和冷静处理紧急事项的能力。这样才是一个合格个程序员👨🏻💻
一、分支命名
不同公司中对Git的使用分支命名规范也略有差异，不过整体都会分为；上线、预发、开发、测试，这样几个分支。如图是一种比较简单使用的拉取分支方式。
- master/main 作为主分支，不可直接修改代码代码，只能从分支合并到主分支进行进行提交。同时，master 分支的合并需要进行审批，审批后才能合并。
- 开发前，先从 master 分支，拉一个开发分支。
2024/10/11/xfg-xxx 使用带有斜线的分支命名会自动创建文件夹，对于多人开发的项目，可以直接归档。 - 后开发，也就是研发已经完成了本地的验证。进行测试时，可以把研发的开发分支合并到 test 分支，提交、部署、测试。遇到测试bug，需要回到可发分支修改代码，之后合并到 test 分支部署验证。
- pre/release 预发分支，用于测试完成后，把研发的开发分支合并到预发分支进行预发上线，上线后测试人员进行验证。最终完成验证后，把开发分支合并到 master 分支，并需要由架构师对合并代码审批通过。最后进行上线开量验证。
- 如果是修复bug的，可以添加一个
fix-用户名缩写-具体功能
这或许是一个对你有用的开源项目，mall项目是一套基于 SpringBoot3 + Vue 的电商系统（Github标星60K），后端支持多模块和 2024最新微服务架构 ，采用Docker和K8S部署。包括前台商城项目和后台管理系统，能支持完整的订单流程！涵盖商品、订单、购物车、权限、优惠券、会员、支付等功能！
- Boot项目：https://github.com/macrozheng/mall
- Cloud项目：https://github.com/macrozheng/mall-swarm
- 视频教程：https://www.macrozheng.com/video/
项目演示：
二、提交规范
保持一个标准的统一的规范提交代码，在后续的评审、检查、合并，都会非常容易处理。
提交规范：type:【需求名】desc #id 如：feat:【抽奖算法】O1、Ologn 时间复杂度算法实现 #需求id（github pr/行云等会有自动关联） 参考Commit message 规范
# 主要type
feat: 增加新功能
fix: 修复bug
# 特殊type
docs: 只改动了文档相关的内容
style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build: 构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert: 执行git revert打印的message
# 暂不使用type
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI（持续集成服务）有关的改动
chore: 不修改src或者test的其余修改，例如构建过程或辅助工具的变动
三、合并分支
在公司中很多时候是大家一起在一个工程开发代码，那么这个时候就会涉及合并代码的。如果有多人共同开发一个接口方法，就会在合并的时候产生冲突。所以要特别注意。
- 选择，你要从哪个分支合并到 test 分支。右键选择 Merge into test
- 如果你合并到test分支的代码，有其他人也在同一行做了改变或者格式化了代码，就会弹出一个合并冲突。这个时候你需要点 Merge 进行合并。
- 在点击 Merge 后，你会看到具体冲突的代码是什么，你可以有选择的从左右合并到中，最后点击 Apply。这个时候要注意不要把让别人的代码合并丢喽。
- 合并完的代码，不要直接 push，你要先本地 install 看是否可以打包。以及如果可以运行的话，可以本地先跑一下。最后 push 提交合并代码即可。
四、回滚代码
如果出现了合并代码冲突后，丢失了代码，那么这个时候一般要进行回滚操作，重新合并。
虽然 Git 提供了回滚代码的功能，但一定要谨慎使用。怎么谨慎？第一个谨慎就是 push 的代码一定确保可以构建和运行，否则不要 push！第二个谨慎是要回滚代码，需要和团队中对应的伙伴打招呼，避免影响别人测试或者上线。
- 先选择要在哪个分支的哪次提交上进行回滚。这里选择的是 test 分支上的提交进行回滚。
- 这里选择 Hard 回滚。因为我们所有的都是合并到 test 分支，所以 test 分支丢失也没问题。可以重新合并。但要和同组伙伴提前说明。
- 回滚后，你会看到代码只剩下从回滚往下的提交内容了。
- 回滚后，你不能直接 push 提交了，这个之后会报错；
fast-forward 因为此时本地分支落后于远程分支。 - 所以要通过
git push origin HEAD --force 进行强制提交。或者你可以把 test 的远程分支删掉，之后在提交。
五、多学实战
Github上标星11K的微服务实战项目mall-swarm，全套 视频教程（2024最新版） 来了！全套教程约26小时，共59期，如果你想学习目前最新的微服务技术栈，同时提高自己微服务项目的开发能力的话，不妨了解下，下面是项目的整体架构图，感兴趣的小伙伴可以点击链接 mall-swarm视频教程 加入学习。
整套 视频教程
的内容还是非常完善的，涵盖Spring Cloud核心组件、微服务项目实战、Kubernetes容器化部署等内容，你也可以点击链接 mall-swarm视频教程 了解更多内容。
推荐阅读
