基于Git Flow与Trunk-Based的分支策略、Code Review与CI/CD集成配置详解
团队从5人扩展到20人后,我们的单体仓库一度陷入“合并地狱”——每周平均37次合并冲突,发布前需要3天冻结代码。本文记录了我们如何用 Git 2.40 + GitLab 16.8 + Jenkins 2.426 重建工作流:主干开发配合短生命周期分支、强制MR与双人Review、流水线卡点。落地后合并冲突降到每周4次,从提交到生产平均耗时从72小时缩短到45分钟。

日常收集工具、经验和可复用的方法。关注技术学习与项目实践,主要分享知识体系搭建、项目实践记录和日常踩坑;喜欢从问题、方案到复盘形成完整闭环。偶尔更新生活观察,主要还是认真做事。
团队从5人扩展到20人后,我们的单体仓库一度陷入“合并地狱”——每周平均37次合并冲突,发布前需要3天冻结代码。本文记录了我们如何用 Git 2.40 + GitLab 16.8 + Jenkins 2.426 重建工作流:主干开发配合短生命周期分支、强制MR与双人Review、流水线卡点。落地后合并冲突降到每周4次,从提交到生产平均耗时从72小时缩短到45分钟。
生产环境一个订单查询接口,压测P95耗时从458ms飙到912ms,数据库CPU直接打满。本文记录一次完整的API性能调优过程:先用cProfile和py-spy定位到90%时间浪费在N+1查询和重复计算上,然后通过SQLAlchemy联合查询、Redis二级缓存、LRU本地缓存三层优化,最终P95降至39ms,吞吐量从320 req/s提升到2100 req/s。文中提供完整可运行的代码示例和压