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

我将代码仓库管理分为以下几个部分：

• 分支管理策略
• 工作流程
• tag版本管理
• 提交格式、日志获取

代码仓库管理

分支管理策略

• master（稳定分支）（保护分支）

  • master+tag（发布版本，里程碑）
  • hotfix（临时分支，补丁分支）

• develop（稳定分支）（保护分支）

  • feature（临时分支，功能分支）
  • release（临时分支，预发布分支）

master和develop是固定受保护、不能直接push的分支。两者区别：

• master始终是最后一次发布的稳定版本
• develop上会有未发布的功能

每个分支的功能独立，便于理解。

工作流程

1. 创建开发分支

   git checkout -b develop master

2. 功能开发

   git checkout -b feature-x develop

3. 功能开发完成，分支合并到develop分支

   git checkout develop
   git merge --no-ff feature-x
   git branch -d feature-x

4. 创建预发布分支

   git checkout -b release-0.1 develop

5. 将预发布合并到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

6. 修补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

7. fork代码，pull request到develop

tag版本管理

上一节提到了用tag打版本，版本号的命名规则：

1. 项目立项

   0.0.0 //主版本.次版本号.修正版本号

   • 主版本号：0表示正在开发阶段；
   • 次版本号：增加新的功能时增加；
   • 修订号：修复bug等改动

2. 开发完成

   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）版本号命名规则