git 使用规范

git使用资料： https://github.com/peak-c/my-git

公司内部使用开发规范：

一. 代码库介绍

1. 个人开发库(git@gitlab.adrd.sohuno.com:spero/xxx_spero.git)
   master：个人主线，始终与发布库的master保持同步。
   feature：功能分支，在master上创建，可以根据需要创建多个feature分支，分支名称可以自定义。
2. 公共发布库(git@gitlab.adrd.sohuno.com:spero/spero.git)
   master：发布库主线，对运维发布的上线代码分支，内容来自release分支的合并。
   release：对测试发布的临时分支，发布人员每周二合并各个feature分支，并对外发布，上线完成后，删除该分支。
   

二. Git工作流

1. 开发新功能
   首先更新自己的master(拉取发布库master代码)，保证是线上的最新代码。然后在master之上创建一个feature分支进行开发，并及时将提交push到个人远端库。
   一个开发周期完成后，发布人员在发布库创建一个release分支，并将要提交测试的各个feature分支进行合并，解决冲突，并打上功能标签。
   测试人员从发布库拉取标签进行测试。
   测试完成后(以见到测试报告为准)，发布人员将release分支合并到master分支，并提交运维进行上线。
2. 测试过程修复bug
   在发布库的release分支之上，创建一个修复bug分支，完成后打上bug修改标签，并合并的release，提交测试人员复测。
3. 线上紧急修复bug
   在发布库上，用线上出问题的标签，创建一个hotfix分支，修复bug。完成后打上bug修复标签，并将该hotfix分支提交测试。
   测试验证完成后，合并到master分支，同时合并到release分支，然后删除该hotfix分支。
   把修复后的新标签提交运维上线。
4. 新需求紧急上线
   可以按第三条线上紧急修复bug的流程，但是标签要打上功能标签。
5. 并行测试
   通常情况下，每个开发周期结束只发布一个测试版本(release)，特殊情况，允许并行发布多个测试版本(release1, release2……)。
   当某个release版本测试完成并上线后，发布人员把该版本同时合并到其他剩余版本中，如有冲突，解决冲突并打上新的标签，并告知相关测试人员影响范围，进行复测。如果两个release要同时发布上线，再创建一个新的release分支，合并这两个分支，进行提测并上线。
6. 新加入成员获取代码
   新加入成员从发布库的master主线拉取代码。
   如果要接替其他人员的开发需求，可以通过对方的个人库clone的方式获取对方最新代码。

三. 标签规范

1. 命名规范
   标签统一以小写v开头的四位数字命名，如v1.0.10.1。
   第1位代表项目在整体功能和设计上有重大的改变。
   第2位代表项目在局部功能和设计上有了较大的改变。
   第3位代表项目添加了一个新功能。
   第4位代表项目在当前功能之上做了几次变动，主要是bug的修复。
2. 创建规则
   在发布release版本时，由发布人员创建功能性标签，也就是确定标签的前三位。
   bug修复人员在该标签的基础上，每修改一次bug，打一次标签，标签号第4位自动加1。
3. 分支命名规则
   release_xxxx：测试分支。
   hotfix_xxx：紧急修复线上bug分支，包括紧急加塞需求，但是在打标签时注释中要描述清楚。

四.注意事项

1. 每次提交的注释尽量写的详细完整，建议使用中文注释，大家统一使用utf8的编码。
2. 创建的标签也要写注释，写清楚该标签的功能或者修复的问题。
3. 提交代码前，自己必须先做diff检查，尽量做到最小改动，不提交无关紧要的东西。
4. 发布库的release分支只能用于修复bug，禁止在上面添加新功能，而且每次修复完bug提交测试前都要打新标签。
5. 多人在一个release分支上修复bug时，要基于这个release分支创建一个新的分支，修复完成后，再合并到原来的release分支上。
6. 禁止在发布库的master上直接push代码或者标签，master的内容只能是来自于release分支的合并。
7. 开发人员在创建feature分支时，一定要保证自己的master和发布库的master一致。
8. 在其他机器上提交代码时，要记得修改本地的global_config，保证能找到代码提交的作者。