一个简单有效的 Git 工作流

Git 使用规范

为了更好的多人协作开发，提高开发、测试的效率，总结出以下简单实用的 git 工作流程。

几个必要的分支

master 为可发布分支，受保护，仅可以merge，不能push，对应生产环境部署的代码；
dev 为开发分支，最初是从 master 分支创建的，用于开发人员日常开发与集成测试；
test 为测试分支，通常不直接push，需要merge request。项目进入测试阶段时从 dev 分支创建，对应测试环境部署的代码；
xxx-feature-xxx 功能分支，自己的功能开发分支，命名以模块或开发账号开始，功能开发并测试完成后删除。

分支管理模式

开发阶段

1. 以 dev 分支为基础创建自己的功能分支，然后在此功能分支上开发，本地开发测试完成后在 gitlab 提交 merge request 合并到 dev 分支（审核人员可选择自己），写清楚标题和描述（相当于提交总结，有重要价值和意义）。
2. 每天上班后先从 dev 分支上 pull 代码，获取所有成员已 push 的代码。若有自己未开发完的功能分支，可以将dev 合并到自己的功能分支，以便在最新的代码上进行下一步开发。
3. 团队 Leader 每天合并一次 dev 到 master。

(dev)$: git checkout -b feature-xxx            # 从dev建立特性分支
(feature-xxx)$: blabla                         # 开发
(feature-xxx)$: git add xxx
(feature-xxx)$: git commit -m '[add] comment'
(dev)$: git merge feature-xxx --no-ff      # 把特性分支合并到dev, 用--no-ff是因为bug-xxx会删除
                                           # 这步可使用 gitlab 的 merge request

测试阶段

1. 从 dev 分支创建一个 test 分支，将 test 分支部署到测试环境，测试人员开始测试并反馈问题到bug系统；
2. test 分支通常不直接 push，而是通过 merge request；
3. 团队 Leader 每天合并一次 dev 分支到 test 分支。
4. 开发人员接收到 bug 后，从 test 分支创建一个 bug 临时分支，在 bug 分支修复后合并到 dev分支进行开发测试。成功后等待下次 dev 分支到 test 分支的合并。若 bug 需要测试人员尽快验证，可直接将 bug 分支提交 merge request 到 test 分支（merge request 的审核人是团队Leader），以上都完成后删除 bug 临时分支。

(test)$: git checkout -b bug-xxx            # 从 test 建立特性分支
(bug-xxx)$: blabla                          # 开发
(bug-xxx)$: git add xxx
(bug-xxx)$: git commit -m '[fix] comment'
(dev)$: git merge bug-xxx --no-ff   # 把bug分支合并到dev, 用--no-ff是因为bug-xxx会删除

5. 在 test 分支的功能修复验证后，团队 Leader 不定期合并 test 分支到 master 分支。

上线阶段

1. 系统上线后会存在两种改动：bug 和优化需求，bug通常当天解决。
2. 一般 bug 直接从 test 分支创建 bug 分支，修复后合并到 test 进行测试，验证通过后合并到 master、test。
3. 紧急 bug 可直接从 master 分支创建 hotfix 分支，修复后合并到 master 分支直接验证，通过后合并到 test、dev。

(master)$: git checkout -b hotfix-xxx         # 从master建立hotfix分支
(hotfix-xxx)$: blabla                         # 开发
(hotfix-xxx)$: git add xxx
(hotfix-xxx)$: git commit -m '[fix] comment'
(master)$: git merge hotfix-xxx --no-ff       # 把hotfix分支合并到master，并上线到生产环境
(dev)$: git merge hotfix-xxx --no-ff          # 把hotfix分支合并到dev，同步代码
(test)$: git merge hotfix-xxx --no-ff         # 把hotfix分支合并到test，同步代码

4. 针对需要优先上线的优化需求，如果 test 分支不含未验证的功能，以 test 分支为基础创建一个 feature 分支进行开发，然后合并到 dev 分支进行开发验证，接着合并到 test 分支进行测试验证，完成后合并到 master 上线。如果 test 分支存在未验证的新功能，则直接以 master 分支为基础创建一个 feature 分支进行开发，完成后合并到 dev 分支进行开发验证，接着合并到 test 分支进行测试验证，最后合并到master分支上线。
   

Commit描述

1. commit提交时的日志书写格式：[action] 描述
2. action 包括 add、fix、improve、Remove、Refactor 等；描述用一句话简要说明变化（最好使用中文，毕竟母语大家好理解，歧义少），若此次提交在 bug 系统上有对应的任务或bug ID，可以写到描述里。
3. 一次提交只做一件事，多个功能要分多次提交。
4. 不要提交不能运行的代码，可以不是最后版本，但要保证能运行，否则可能别人 pull 后运行报错。
5. 不要提交本地自动生成或临时用来测试的文件，如pyc，可在 .gitignore 里配置忽略这些文件。