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环境。