git使用资料： https://github.com/peak-c/my-git
公司内部使用开发规范：
一. 代码库介绍
- 个人开发库(git@gitlab.adrd.sohuno.com:spero/xxx_spero.git)
master：个人主线，始终与发布库的master保持同步。
feature：功能分支，在master上创建，可以根据需要创建多个feature分支，分支名称可以自定义。 - 公共发布库(git@gitlab.adrd.sohuno.com:spero/spero.git)
master：发布库主线，对运维发布的上线代码分支，内容来自release分支的合并。
release：对测试发布的临时分支，发布人员每周二合并各个feature分支，并对外发布，上线完成后，删除该分支。
二. Git工作流
- 开发新功能
首先更新自己的master(拉取发布库master代码)，保证是线上的最新代码。然后在master之上创建一个feature分支进行开发，并及时将提交push到个人远端库。
一个开发周期完成后，发布人员在发布库创建一个release分支，并将要提交测试的各个feature分支进行合并，解决冲突，并打上功能标签。
测试人员从发布库拉取标签进行测试。
测试完成后(以见到测试报告为准)，发布人员将release分支合并到master分支，并提交运维进行上线。 - 测试过程修复bug
在发布库的release分支之上，创建一个修复bug分支，完成后打上bug修改标签，并合并的release，提交测试人员复测。 - 线上紧急修复bug
在发布库上，用线上出问题的标签，创建一个hotfix分支，修复bug。完成后打上bug修复标签，并将该hotfix分支提交测试。
测试验证完成后，合并到master分支，同时合并到release分支，然后删除该hotfix分支。
把修复后的新标签提交运维上线。 - 新需求紧急上线
可以按第三条线上紧急修复bug的流程，但是标签要打上功能标签。 - 并行测试
通常情况下，每个开发周期结束只发布一个测试版本(release)，特殊情况，允许并行发布多个测试版本(release1, release2……)。
当某个release版本测试完成并上线后，发布人员把该版本同时合并到其他剩余版本中，如有冲突，解决冲突并打上新的标签，并告知相关测试人员影响范围，进行复测。如果两个release要同时发布上线，再创建一个新的release分支，合并这两个分支，进行提测并上线。 - 新加入成员获取代码
新加入成员从发布库的master主线拉取代码。
如果要接替其他人员的开发需求，可以通过对方的个人库clone的方式获取对方最新代码。
三. 标签规范
- 命名规范
标签统一以小写v开头的四位数字命名，如v1.0.10.1。
第1位代表项目在整体功能和设计上有重大的改变。
第2位代表项目在局部功能和设计上有了较大的改变。
第3位代表项目添加了一个新功能。
第4位代表项目在当前功能之上做了几次变动，主要是bug的修复。 - 创建规则
在发布release版本时，由发布人员创建功能性标签，也就是确定标签的前三位。
bug修复人员在该标签的基础上，每修改一次bug，打一次标签，标签号第4位自动加1。 - 分支命名规则
release_xxxx：测试分支。
hotfix_xxx：紧急修复线上bug分支，包括紧急加塞需求，但是在打标签时注释中要描述清楚。
四.注意事项
- 每次提交的注释尽量写的详细完整，建议使用中文注释，大家统一使用utf8的编码。
- 创建的标签也要写注释，写清楚该标签的功能或者修复的问题。
- 提交代码前，自己必须先做diff检查，尽量做到最小改动，不提交无关紧要的东西。
- 发布库的release分支只能用于修复bug，禁止在上面添加新功能，而且每次修复完bug提交测试前都要打新标签。
- 多人在一个release分支上修复bug时，要基于这个release分支创建一个新的分支，修复完成后，再合并到原来的release分支上。
- 禁止在发布库的master上直接push代码或者标签，master的内容只能是来自于release分支的合并。
- 开发人员在创建feature分支时，一定要保证自己的master和发布库的master一致。
- 在其他机器上提交代码时，要记得修改本地的global_config，保证能找到代码提交的作者。