共计 1319 个字符，预计需要花费 4 分钟才能阅读完成。
开发和维护个人开源项目之代码仓库管理
我将代码仓库管理分为以下几个部分：
分支管理策略
工作流程
tag 版本管理
提交格式、日志获取
代码仓库管理
分支管理策略
master（稳定分支）（保护分支）
master+tag（发布版本，里程碑）
hotfix（临时分支，补丁分支）
develop（稳定分支）（保护分支）
feature（临时分支，功能分支）
release（临时分支，预发布分支）
master 和 develop 是固定受保护、不能直接 push 的分支。两者区别：
master 始终是最后一次发布的稳定版本
develop 上会有未发布的功能
每个分支的功能独立，便于理解。
工作流程
创建开发分支
git checkout -b develop master
功能开发
git checkout -b feature-x develop
功能开发完成，分支合并到 develop 分支
git checkout develop
git merge –no-ff feature-x
git branch -d feature-x
创建预发布分支
git checkout -b release-0.1 develop
将预发布合并到 master 和开发分支
git checkout master
git merge –no-ff release-0.1
git tag -a 0.1
git checkout develop
git merge –no-ff release-0.1
git branch -d release-0.1
修补 bug
git checkout -b fixbug-0.1 master
git checkout master // 合并到主线
git merge –no-ff fixbug-0.1
git tag -a 0.1.1
git checkout develop // 合并到开发分支
git merge –no-ff fixbug-0.1
git branch -d fixbug-0.1
fork 代码，pull request 到 develop
tag 版本管理
上一节提到了用 tag 打版本，版本号的命名规则：
项目立项
0.0.0 // 主版本. 次版本号. 修正版本号
主版本号：0 表示正在开发阶段；
次版本号：增加新的功能时增加；
修订号：修复 bug 等改动
开发完成
1.0.0
主版本号：全盘重构时增加；重大功能或方向改变时增加；大范围不兼容之前的时增加；
次版本号：增加新功能时增加；
修订号：修复 bug、功能调整等改动
提交格式、日志获取
规范化的提交对后续的整理、回溯是很友好的，比如：realse 的时候进行一轮日志获取就能生成版本变更信息（版本开发之前应有计划）。
规范化 commit message
提交类型（友好提醒）
提交信息格式
提交信息验证
changelog 生成
conventional-changelog-cli 工具
我是详细实践，请点我：Git commit message 和工作流规范
总结
本文主要对代码仓库的管理作了整理，这个也是每个项目启动之时就应该设计好的。
参考链接
Git 工作流程 Git 分支管理策略团队协作中的 Github flow 工作流程 Commit message 和 Change log 编写指南如何写好 Git commit messages 优雅的提交你的 Git Commit Message 接口（Api）版本号命名规则
