<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>工程规范 on LeafCxy's Blog</title><link>https://leafcxy.github.io/tags/%E5%B7%A5%E7%A8%8B%E8%A7%84%E8%8C%83/</link><description>Recent content in 工程规范 on LeafCxy's Blog</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Wed, 23 Sep 2026 09:17:00 +0800</lastBuildDate><atom:link href="https://leafcxy.github.io/tags/%E5%B7%A5%E7%A8%8B%E8%A7%84%E8%8C%83/index.xml" rel="self" type="application/rss+xml"/><item><title>Git 分支管理规范：深入拆解经典 GitFlow 工作流与团队协作实践</title><link>https://leafcxy.github.io/posts/2026/09/git-branch-management-gitflow-guide/</link><pubDate>Wed, 23 Sep 2026 09:17:00 +0800</pubDate><guid>https://leafcxy.github.io/posts/2026/09/git-branch-management-gitflow-guide/</guid><description>&lt;p&gt;在个人开发时代，我们习惯了在本地直接对 &lt;code&gt;main&lt;/code&gt; 或 &lt;code&gt;master&lt;/code&gt; 分支疯狂 commit，代码改完直接 &lt;code&gt;git push -f&lt;/code&gt; 甚至一路绿灯。然而，当团队规模扩大到十人、百人，当多条业务线并行推进、线上频繁需要紧急修 Bug、版本需要定期切出封版测试时，缺乏规范的 Git 操作就会演变成一场场灾难：&lt;/p&gt;</description></item></channel></rss>