Git工作流说明

分支规范

• 1. master 主分支，对应完全稳定的测试环境的代码，其它分支的最终依赖，所有审核通过的代码都会在某个时间点合并到master分支。
• 2. dev 对应的是开发环境的代码。当功能分支开发完毕之后，首先会被合并到dev分支，自测通过后合入master发测试版，测试验证后合入release发正式版。
• 3. release 已经发布或即将发布版本的代码，用于发布正式版本（每个版本对应一个tag），其应当派生自master分支，并且只执行从master合并更新、打tag等操作不应该有新提- 交。
• 4. hotfix-* 修复分支(*处写明要修复的问题)，对应补丁代码，用于对release分支进行紧急修复或者更新补丁。这些分支应当派生自release分支，开发完成后先合dev自测、之后- 合master交测试同学验证、再之后合回release发版确认修复效果。
• 5. feature-* 功能分支(*处写明feature名称)，开发同学主要日常工作分支，用来开发新功能原则上每个功能一个独立的分支。这些分支应当都是从release分支派生出来，最终也应该合并回release分支。每个功能开发完成后先合dev自测、之后合master交测试测试、再之后合release发版上线。

一些硬性要求

• 0. commit messages 要有意义，这最最基本的要求
• 1. 每一个变更commit一次，而不是合并多个变更一起提交
• 2. 永远不要对已push的commits进行rebase
• 3. 永远不要在release分支直接提交代码
• 4. 不懂cherry-pick的同学修复bug时，必须从release分支派生hotfix-*分支再改代码

一些默认约定

• 1. 任何时刻的master、release分支代码都是稳定的可以用来部署发版的
• 2. 使用功能分支feature-*进行开发，而不是直接在master分支上提交代码，任何新功能都需要从master派生出一个分支，并且为其起一个描述新变更内容的名字：比如 - feature-oauth2-scopes
• 3. 除了紧急bug修复从release派生新分支以外，其它所有新分支从master派生，并最终合并回master（新分支从哪个分支派生，最终也应该合回那个分支，原则上不应该从mater、- release以为的分支派生新分支）
• 4. 只有在完成自测且review通过之后，新分支才允许合并到 master 分支
• 5. 一旦新分支被合并推送至master分支，master分支应当立即进行部署
• 6. 所有发布版本都应建立在tag上
• 7. 在合并代码之前进行code review，而不是在合并之后
• 8. 以分支进行自动化的部署
• 9. tag由人来设定，而不是CI