1. git&GitFlow
1.1. git使用
暂无
1.2. GitFlow版本分支管理策略
GitFlow开发模型从源代码管理角度对通常意义上的软件开发活动进行了约束。为我们的软件开发提供了一个可供参考的管理模型。GitFlow开发模型让开发代码仓库保持整洁，让小组各个成员之间的开发相互隔离，能够有效避免因处于开发状态中的代码相互影响而导致的效率低下和混乱。
所谓开发模型，在不同的开发团队，不同的文化，不同的项目背景、规模、复杂程度的情况下都有可能需要进行适当的裁剪或扩充。
1.2.1. GitFlow的常用分支
GitFlow的常用分支包括master、develop、feature、release、hotfix，其中master、develop是远程分支，feature、release、hotfix是本地分支。远程分支是指需要push到gitlab、github远程仓库中。本地分支指开发人员的本地开发时使用的git版本控制环境。
1.2.2. GitFlow的流程图如下
需要掌握每个分支的用途，何时创建分支，从哪个分支产生，合并到哪个分支去。
1.2.3. master分支
Ø 主分支，Master分支是最为稳定的，功能比较完整的，随时可发布生产环境的代码。注意永远不要在 master 分支上直接开发和提交代码，以确保 master 上的代码一直可用。
Ø master分支是唯一的只读分支，只能从其他分支(release/hotfix)合并，不能在此分支修改。
Ø 另外所有在master分支的推送应该打标签做记录,方便追溯，例如release合并到master，或hotfix合并到master，都需要打tag。
1.2.4. develop分支
Ø 用作平时开发的主分支，并一直存在，永远是功能最新最全的分支，基于master分支克隆（仅一次）
Ø feature功能分支完成，自测通过，合并到develop，然后删除feature分支
注意：禁止将未编译或编译不通过的代码提交到远程仓库，如果编码工作进行未完成可以提交到本地仓库中，等待该功能点全部实现并自测通过后再将代码推送到远程仓库中。
Ø 当develop分支搜集了需要上线的所有功能，即包含所有要发布到下一个release的代码，从develop分支拉取release分支 , 进行提测
Ø release/hotfix 分支上线完毕 , 合并到develop并推送
1.2.5. feature分支
Ø 功能开发分支，主要用来开发新的功能，基于develop分支克隆，功能开发完毕，并自测通过后合到develop分支
Ø feature分支可同时存在多个，用于团队中多个功能同时开发，属于临时分支，功能完成后可选删除
1.2.6. release分支
Ø 测试分支，主要用于提交给测试人员进行功能测试，基于feature分支合并到develop之后，从develop分支克隆
Ø 测试过程中发现的BUG在本分支进行修复，修复时创建修复分支bugfix-*，修复完成所有bug上线后一次性合并到develop/master分支并推送(完成功能)，在master分支打Tag
Ø 属于临时分支, 功能上线后可选删除
注意：如果开始了release分支的测试之后，不允许再将develop分支的新功能合并到release分支，因为release分支已经开始测试，如果合并新功能则需要全部重新测试，尽量将新功能放到下一个release版本中发布。
1.2.7. hotfix分支
Ø 补丁分支，基于master分支克隆 , 主要用于对线上的版本进行BUG修复
Ø 修复完毕后合并到develop/master分支并推送 , 并在master分支打Tag
Ø 属于临时分支 , 补丁修复上线后可选删除
Ø 所有hotfix分支的修改会进入到下一个release
1.3. gitflow开发实践
gitflow开发实践需要结合jira一起使用，后期会搭建持续集成平台时，再结合gitlab、maven、Jenkins、sonarqube等工具继续完善。
1.3.1. 提交的准则
Ø 除了源码相关的东西之外，其他build产生的东西（如：maven的target文件夹，.idea文件夹等），均不能提交进入源码仓库，添加到.gitignore文件中忽略掉。
Ø 开发人员要严格按照我们约定的gitflow版本分支管理流程切换到指定分支，开发相应的功能。
Ø 任务完成后需要根据测试用例经过严格的自测才能推送develop，严禁将编译不通过，提交不完全的代码推送到远程分支。
1.3.2. 命名约定
Ø 主分支名称：master
Ø 主开发分支名称：develop
Ø 标签（tag）名称：v*. release，其中“*” 为版本号，“release” 小写，如：v1.0.0. release
Ø 新功能开发分支名称：feature-*，其中“*” 为对应jira上的任务编号
Ø 发布分支名称：release-*，其中“*” 为版本号，“release”小写，如：release-1.0.0，release分支上修复bug的分支名称为bugfix-*
Ø master的bug修复分支名称：hotfix-*，其中“*” 为对应jira上的任务编号
1.3.3. 开发人员开发步骤
1) 开发人员的任何工作，包括新功能开发任务、修改release的bug，修改master上的hotfix都需要在jira上创建对应类型的问题，开发任务是开发人员自己创建，release和master上的bug是测试人员创建，比如SUZHENGXIA-347，然后开人员去完成任务或修复bug时创建对应的分支。
2) 创建功能分支：在工程的develop分支创建名称为feature-347的功能分支，在创建分支前，最好先拉取下最新的代码，因为有可能其他人提交了自测通过的代码。
保证当前分支是最新的develop分支，在项目上右击依次选择，git—repository—Branches…
选择New Branch
输入分支名称feature-347
3) 当新功能完成，并根据测试人员提供的测试用例自测通过之后合并feature-347到develop分支。
将当前分支切换到develop分支，然后进行一次拉取操作，一方面拉取最新的代码，另一方面防止冲突，出现冲突先解决冲突。
选择feature-347分支，进行Merge into Current操作即完成合并到develop操作。
1.3.4. 实践中遇到的问题
1) feature管理
自己团队管理自己的feature，数量少，每天站会沟通一下即可，合并后的feature也及时删除，同一时间的feature数量基本固定在一个规模。用腾讯云在线编辑工具维护一份文档来管理。
2) 数据库脚本管理
方式一：开发人员自己整理脚本
每个feature一个脚本目录，没有脚本的也要弄个空目录，最后发布了多少feature，就多少个脚本目录，发布前有人整理成批处理一键执行。脚本提交时间，在feature合并后必须提交脚本，测试人员连带功能和脚本都测试完毕才算完毕，大家把脚本统一放到一个目录。
方式二：整个项目组的脚本统一的由一个人来负责整理
脚本负责人一般为合并负责人、发布人，在设计阶段将功能所需要的数据库脚本整理好，如果后期有变动需要通知脚本负责人，当创建release分支时，创建当前版本的脚本目录，变更日志，然后提交上UAT环境。