Git Flow与Trunk Based双轨制:团队协作与CI/CD集成方案
本文记录了我们团队从混乱的Git使用到建立规范工作流的全过程。针对12人研发团队、每周20+次合并的现状,我们设计了“Trunk Based为主、Git Flow为辅”的双轨制分支策略,配合基于GitLab的MR强制Code Review流程,以及Jenkins Pipeline自动化的CI/CD集成方案。通过引入pre-commit钩子、规范提交信息、自动化测试门禁,将代码冲突率从平均每周8次降

关注品牌与内容,长期记录用户研究、产品可用性分析和从需求到交付的完整过程。相信长期积累胜过短期追热点,希望用清晰的方法帮助产品与业务更高效地落地。
本文记录了我们团队从混乱的Git使用到建立规范工作流的全过程。针对12人研发团队、每周20+次合并的现状,我们设计了“Trunk Based为主、Git Flow为辅”的双轨制分支策略,配合基于GitLab的MR强制Code Review流程,以及Jenkins Pipeline自动化的CI/CD集成方案。通过引入pre-commit钩子、规范提交信息、自动化测试门禁,将代码冲突率从平均每周8次降
一个线上接口从平均响应1200ms压到180ms,吞吐量提升6.5倍。本文记录一次完整的API性能调优过程。通过cProfile与py-spy定位到瓶颈不在数据库而在序列化与重复查询;随后引入SQLAlchemy 2.0的selectinload预加载、Redis二级缓存以及gzip中间件,最终在wrk压测下(500并发,60秒)P99延迟从2.1s降至320ms。全程基于FastAPI 0.10
某个凌晨两点,线上告警群里炸了锅——订单导出接口平均响应时间飙到850ms,数据库连接池被打满。排查后发现,罪魁祸首是串行调用三个下游HTTP服务(用户服务、库存服务、价格服务),每个耗时250ms左右。本文记录了我用Python 3.10原生的asyncio + httpx将该接口从同步阻塞改为异步并发,在不引入Celery等重型中间件的前提下,将P95延迟从1.2s压到180ms,数据库连接数