开发和维护个人开源项目之代码仓库管理

开发和维护个人开源项目之代码仓库管理我将代码仓库管理分为以下几个部分：分支管理策略工作流程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 developgit merge –no-ff feature-xgit branch -d feature-x创建预发布分支git checkout -b release-0.1 develop将预发布合并到master和开发分支git checkout mastergit merge –no-ff release-0.1git tag -a 0.1git checkout developgit merge –no-ff release-0.1git branch -d release-0.1修补buggit checkout -b fixbug-0.1 mastergit checkout master //合并到主线git merge –no-ff fixbug-0.1git tag -a 0.1.1git checkout develop //合并到开发分支git merge –no-ff fixbug-0.1git branch -d fixbug-0.1fork代码，pull request到developtag版本管理上一节提到了用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）版本号命名规则