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

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

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

• 分支管理策略
• 工作流程
• 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和工作流规范

总结

本文主要对代码仓库的管理作了整理，这个也是每个项目启动之时就应该设计好的。

参考链接