LenSung’s Git Work Flow 为不同的分支分配了一个很明确的角色，定义了分支之间何时进行什么样的交互，并且规范了提交信息。

git使用版本 - 图1

主要分支

首先，项目存在两个长期的主要分支。

  • 主分支 master
  • 开发分支 develop

master 分支用于存放对外发布的版本，任何时候在这个分支上拿到的都是稳定的发布版；且 master 分支不允许有任何提交记录，仅接受从其它分支（release hotfix）提交的 Pull Requests（下文简称为 PR）；因此，master 分支每次接受 PR 提交时都应该分配一个版本号并打上 Tag。
develop 分支用于日常开发，作为功能的聚合分支，存放最新的开发版本；并且 develop 分支也不允许有任何提交记录，仅接受来自功能分支（feature/fix）的 PR 或 热修复分支（hotfixe）的 cherry-pick（下文简称为 CP）。

协助分支

其次，项目存在三种协助分支。

  • 个人分支 feature/fix
  • 预发布分支 release
  • 热修复分支 hotfix

feature/fix 分支是从 develop 分支中 checkout 出来的新分支，每个产品需求或测试的 BUG 对应一个 feature/fix 分支，一旦开发完成并且在本开发周期内要上线，将被要求向 develop 分支提交 PR，待 Review 通过后允许合入；建议命名为 feature-xxx/fix-xxx 关联相关产品需求或 BUG（xxx 为 Gitee 任务编号）。
release 分支是每个开发周期初（如每周一）从 master 分支 checkout 出来的新分支，且 release 分支会自动构建测试版本，开发完成并且在本开发周期内要上线的 feature/fix 分支内的所有提交被允许 CP 到该分支就行测试；全部测试通过后由项目负责人向 master 分支提交 PR 合入完成上线；建议命名为 release-xx 关联开发周期（xx 为本年度第 xx 周）。
hotfix 分支是从 master 分支 checkout 出来用于修复线上发现的严重 BUG；BUG 修复完成后将被要求向 master 分支提交 PR，待 Review 通过后由项目负责人合入，并同时要求向 develop 分支 CP 本次修复的所有提交；建议命名为 hotfix-xxx 关联相关 BUG（xxx 为 Gitee 任务编号）。 协助分支一旦开发完成请定期删除，防止代码仓库过分臃肿。

2. 使用流程

新项目

创建项目目录并进入

  1. mkdir mini-redux
  2. cd mini-redux

初始化项目仓库

git init

创建 README.md

touch README.md

保存并提交

git add README.md
git commit -m "Initial commit"

关联并推送到 gitee

git remote add origin git@gitee.com:smhlensung/mini-redux.git
git push -u origin master

此步骤一般由项目负责人进行。

老项目

进入项目目录

cd mini-redux

关联并推送到 gitee

git remote add origin git@gitee.com:smhlensung/mini-redux.git
git push -u origin master

此步骤一般由项目负责人进行。

创建 develop 分支

从 master 分支创建 develop 分支

git checkout master
git pull origin master
git checkout -b develop

推送到 gitee

git push --set-upstream origin develop

此步骤一般由项目负责人进行。

创建 release 分支

每个开发周期初从 master 分支创建 release 分支

git checkout master
git pull origin master
git checkout -b release-22

分支命名

release-xx（xx 为本年度第 xx 周）