共计 3006 个字符，预计需要花费 8 分钟才能阅读完成。
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 环境。
