Skip to the content.

Tars Framework Git合作规范

简介

TarsFramework项目中的TarsRegistry、TarsNode、TarsProperty…等应用依赖于TarsCpp项目,TarsCpp项目依赖于TarsProtocolTarsWeb为TarsFramework的Web管理端,为了更好的提供Tars的多版本支持和迭代,选定v2.4为Tars的第一个LTS版本,并在这第一个LTS版本中将TarsCpp、TarsProtocol、TarsWeb、TarsFramework四个项目的主版本和子版本进行统一。

版本规划

版本号定义:v{主版本}.{子版本}.{build号}

Git合作规范

首先欢迎各位志同道合的伙伴为社区贡献自己的力量,在源码合作时请遵循以下规范

  1. 请先fork对应的GitHub仓库
  2. 在开发之前请谨记,release/x.x为对应版本的发布分支,这个分支相当于单版本项目仓库的master分支
  3. 务必在动手之前先拉取远端仓库对应release分支的最新变动到本地release分支,避免出现合并冲突
  4. 请从本地对应版本的release分支检出一个feature分支进行功能开发,feature分支命名规范为:feature/{Git用户名}/{需求名称},如:feature/franklee/correct_error_message_on_property_table_missing
  5. 若是紧急修复,请检出hotfix分支,命名规范为:hotfix/{Git用户名}/{需求名称},如:hotfix/franklee/fix_wrong_typing_on_servant_status_enum_define
  6. 开发完成后请务必先对对应的feature或hotfix分支进行充分测试
  7. 测试完成后,请将当前的feature分支合并到本地的release分支
  8. 提交Pull Request到远端仓库release分支,并撰写必要说明

详细工作流见下图:

Tars Framework Git Flows

特别注意

  1. 远端仓库:TarsCloud/xxx 的官方仓库
  2. 远端分支:远端仓库TarsCloud/xxx下的分支
  3. 本地仓库:从远端仓库fork出来的仓库
  4. 本地分支:从本地仓库检出的分支
  5. 为了保证master版本与最新版release分支同步,最新版本框架的release版本在发布完成后需要合并到master
  6. 只有新开release版本才需要从master检出
  7. 严禁合并除最新版release分支以外的分支到master