Git Flow与Trunk Based双轨制:200人团队分支策略与CI/CD联动实践
在某中型研发中心(200+工程师),我们曾因Git分支混乱导致每周平均3次误合并、发布窗口长达4小时。本文记录我们如何将Git Flow与Trunk Based Development按业务场景混合落地,配合GitLab MR(Merge Request)强制Code Review流水线,以及Jenkins + Argo CD的CI/CD联动。文中提供完整的`.gitlab/merge_reque

Engineer,重视稳定性、可维护性和效率,主要关注React前端开发,分享项目踩坑复盘、浏览器原理及真实项目复盘;喜欢从问题、方案到复盘形成完整闭环。希望这些经验能帮你少踩几个坑。
在某中型研发中心(200+工程师),我们曾因Git分支混乱导致每周平均3次误合并、发布窗口长达4小时。本文记录我们如何将Git Flow与Trunk Based Development按业务场景混合落地,配合GitLab MR(Merge Request)强制Code Review流水线,以及Jenkins + Argo CD的CI/CD联动。文中提供完整的`.gitlab/merge_reque
本文记录了一次真实的API性能调优过程。一个基于FastAPI+SQLAlchemy的订单查询接口,在压测中P95延迟高达198ms,QPS仅320。通过py-spy定位到90%耗时在数据库N+1查询和JSON序列化上。采用`selectinload`批量加载替代懒加载、引入`aiocache`+Redis缓存热点数据、并用`orjson`替换默认JSON解析器后,P95延迟降至32ms,QPS提