如何将master分支维护为仅包含版本发布提交？

嘿，这个模式其实是很多成熟开源项目都在用的「纯净发布分支」实践，我来给你拆解几个核心技巧，确保master分支始终只保留版本发布的干净提交：

1. 严格的分支角色分工 #

首先得把分支职责划死：

• master分支：只做一件事——承载正式发布的版本提交，绝对不允许直接在上面写代码或者提交小改动。
• 开发分支：比如命名为develop，所有日常功能开发、bug修复都在这里进行，甚至可以再拆分出feature/xxx、bugfix/xxx这类子分支，最终都合并到develop。

简单说就是：master是“成品仓库”，develop是“车间流水线”，两者严格隔离。

2. 用「Squash合并」压缩迭代内容到master #

这是保证master提交干净的关键操作。当develop上的迭代完成（比如一个版本的功能都开发、测试完毕），执行以下步骤：

# 切换到master分支
git checkout master
# 把develop上的所有提交压缩成一个新的提交
git merge --squash develop
# 撰写清晰的版本提交信息，比如：
git commit -m "v2.3.0: 新增用户中心模块，修复3个已知bug，优化接口响应速度"

这样，master上就只会新增一个对应版本的独立提交，所有开发过程中的细碎提交都被“打包”进去了，完全看不到中间过程。

3. 用标签（Tag）绑定版本提交 #

每个master上的版本提交，一定要打一个对应的语义化版本标签，方便后续快速定位：

# 打带注释的标签
git tag -a v2.3.0 -m "Release version 2.3.0"
# 推送标签到远程仓库
git push origin v2.3.0

标签就像版本的“快照书签”，别人想找某个版本的代码，直接拉对应标签就行，不用在master的提交历史里翻。

4. 给master加权限防护（平台层面） #

光靠自觉不够，得在Git平台上给master分支加保护规则：

• 禁止直接向master分支push代码，所有修改必须通过PR（Pull Request）。
• 强制PR只能用「Squash合并」，禁用普通合并、Rebase合并选项。
• 可选：设置PR必须经过至少1个代码审核才能合并。

从流程上堵死乱提交的可能，保证只有经过审核的、压缩后的版本提交才能进入master。

5. 发布后同步回开发分支 #

版本发布到master后，记得把master的最新提交合并回develop，避免两个分支出现差异：

git checkout develop
git merge master
git push origin develop

因为master的提交是干净的单一提交，合并时几乎不会有冲突，保证后续开发基于最新的发布版本进行。

举个实际的小例子，帮你理顺：

1. 日常开发：在feature/login-module分支开发登录功能，完成后PR到develop分支，合并方式随意（因为develop是开发分支，不需要太干净）。
2. 准备发布：测试确认develop上的所有功能没问题，切换到master执行Squash合并。
3. 提交版本信息：写清楚版本号和核心变更点，提交到master。
4. 打标签：给这个版本提交打上对应的v1.2.0标签并推送。
5. 同步回develop：把master的版本提交合并到develop，保证开发分支和发布分支同步。

这样一套操作下来，master的提交历史就会像你提到的例子一样，每个提交对应一个清晰的版本，干净又好维护~

内容的提问来源于stack exchange，提问作者lysergic-acid