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视频教程 了解更多内容。
