Git代码仓库使用规范

一、目标

代码仓库规范、敏捷、Devops、构建-测试-准生产-生产流水线、线上操作规范、监控预警 写码规范、单元测试规范、

二、使用原则

1. 了解差异，适用场景
2. 结合公司团队现有使用情况，作最小化变更切入
3. 通过引入工具、脚本化等方式把git的一些高级特性用起来

三、我司当前代码仓库使用

1、代码仓库使用场景

代码仓库使用：

给出仓库地址-> 拉取代码-> maven拉取依赖->本地单元测试、运行->调改代码/新加功能 提交代码

协同开发常见问题：

代码冲突：

场景：成员改动本地代码，拉取远端代码时 远端相同代码块也被改动。发生在拉取人本地环境。

避免：功能模块化合理分配到人 避免多人同时对同一模块代码编辑，对于公共代码(CONST常量、工具类)改动后及时提交并通知组员更新

冲突覆盖：

场景：上一步中代码拉取人，未能合适的处理好冲突，如导致自己代码片断或他人代码片段丢失。或合并时未能与他人沟通导致合并后的代码未能满足冲突干系人的需求。

避免：首先冲突处理人(一般是后提交的 pull过程中出现)要熟悉一种客户端进行冲突处理，处理时与团队成员沟通让对方校对。 建议把自己的代码片段copy一份后，先以对方代码为准处理冲突 再把自己代码应用上来。

线上发布覆盖：

场景：如张三李四 2人协同开发，张三做了个功能A 本地打包发了线上，但代码未提交远端仓库 之后李四做了功能B 也在自己本地构建打包发于线上 导致张三的功能A在线上环境被移除。或张三也提交了远端，但李四构建打包时未能拉取远端代码更新，同样导致张三的功能A在线上环境被移除。

避免：以远端代码如master分支作为线上代码基线，由持续集成工具或是指定发布人基于此分支代码做发布操作。 不同开发成员做的功能点，不merge到master就不会发布到线上。

产品功能回滚：

场景：6.4新发布了 A B C 三个功能模块，6.5中 上一版的C功能模块不要了(原6.4版本继续保持服务 只是6.5中不用它)， 后续是否启用未知。

建议：对非确定性功能模块，以后面会提到的Feature Toggle代码开关模式。不启用此功能时 代码编译仍处理但运行时相关@Controller, @Service, @Repository不会加载到运行时。除非反射加载class否则不对业务入口或是rpc请求做响应。

对写码兄弟的要求：

1. 按功能模块一次提交多个文件，提交要有注释

2. 注意IDE格式化问题，避免改一行导致整个源文件格式变动

3. 按时、按量、按功能块定时提交代码并push, 按一定周期拉代码避免冲突。拉代码在把本地文件先提交本地repo后进行，有冲突时按上面的冲突情况处理

2、gogs仓库情况

合理命名group组织：

按技术团队分组：(例) 产品组、设计组、IOS、Anz、后端业务组、前端组、架构支撑组、运维支撑组 人个分组加上前缀作区分：(例) staff-xxx ym-xxx

仓库命名：

伟大的仓库名称一般都较短、令人深刻并且 独一无二 的。 (建议都用横杆做连接符如 support-common，不用下划线)

合理组织仓库内代码内容，不让代码allInOne(代码成为巨无霸 很多人参与 易冲突) 。也不要让仓库内功能块过于稀疏(仓库N多个，每个repo没啥提交量 干洗成员参与进来要clone N多个repo)。建议根据仓库作用类型 结合Maven项目结构来组织子项目模块，维护人员以3-5人(支撑项目)，5-12人(核心业务项目)

gogs服务器 TODO：

gogs版本升级 (当前ver 0.9.48.0722 不支持分支保护push白名单模式)

3、公司团队代码、依赖构建、项目差异化情况

技术团队、项目组划分：

app端 anz: 构建工具：maven (结合jenkins 做单元测试? 点击测试、构建打包apk)

ios: ??

前端： 构建工具：webPack、browserIfy、gulp、Grunt、FIS

JAVA后端： 项目： oceans: (工程组： 部署包、公用jar包) app-api: (多版本线上部署、版本分支bugfix) app-site: (trunk主干开发， 无特殊分支) cms-ts: (2.29, arm?)

构建工具： maven 单元测试、mock测试

支撑平台、架构组工具包： 语言：java为主，可能出现的有 shell, groovy, python, golang common: mongo-plugin rabbitmq-client redis-plugin file-server yame-tool

ecpark: common-server drive-service drive-service-api obd-server-proto obd-server-tlv job-server mongo-test canal-mongo ecpark-deamon ecpark-communication obd-service-parent

四、代码仓库常见开发流程

1、单主干

单主干的分支实践（Trunk-based development，TBD）在 SVN 中比较流行。Google 和 Facebook 都使用这种方式。

2、github flow

githubflow非常简单，只有一个固定的远程分支marter。每个研发人员fork项目后，在本地用功能分支开发，开发完成后提交PR请求合并master分支。

3、git flow

git-flow 应该是目前流传最广的 Git 分支管理实践。适用于有较长版本发布周期的项目。(我司周期 产品需求池 一个月?) git-flow 流程中包含 5 类分支，分别是 master、develop、新功能分支（feature）、发布分支（release）和 hotfix。这些分支的作用和生命周期各不相同。

git flow争议 目前推崇的做法是持续集成和随时发布。

*这是最早由Web developer Vincent Driessen和他所在的组织采用并总结出的一套工作流程。Gitflow不是Git社区的官方推荐工作流，这不是Linux内核开发的工作流也不是Git开发的工作流。

*Github对Gitflow里的某些部分有不同看法，他们利用简化的分支模型和Pull Request构建了适合自己的工作流Github Flow。Gitflow也不是Github所推荐的工作流。

feature branch模型替代:

Feature Toggle技术

利用Spring的Conditional注解来实现FeatureToggle 也可以试试Branch by Abstraction

五、基于git flow 的简化设计

目标：由简入深、工具流水化、开发视角最简化、切合促进现有流程而非阻碍、限定。

1、适用申明

下面的2个设计适用于java类项目，优先覆盖架构组、java后端

其它团队及项目特别会有差异，应以团队中各自细化使用流程为准。

2、通用项目

大向而言，借鉴git flow的master、develop长身命周期的分支，参考TBD单主干。适用于工具jar包构建发布、主线版本部署、固定少量成员维护的代码仓库。

master：分支保护；防删 gogs push 白名单；防乱提交 (gogs版本>0.10.x) develop：设为默认分支； pull/push： develop -> develop

设计：

1. 安全通用化：通过在gogs仓库做设定，约定master为主线发布分支，开启分支保护。设定develop为默认分支，成员拉取时： develop <- origin/develop

2. 开发视角最简化：只关注develop分支 本地git add . git commit -m "xxx"提交； git pull/push 远端。(关于流程简化与git使用深度的问题... 满足使用需要，最大化操作效率)

3. 工具流水化：限定push白名单，由JENKINS流程化进行merge操作 打tag，再由其基于master进行线上发布。(master merge时不会有冲突) 避免人工merge操作进而带来额外工作量

4. 不阻碍、不限定：类似SVN TBD流水模式 易上手。不做太多约定对团队成员形成约束阻碍。同时模式为gitflow简化版可轻易借鉴gitflow进行拓展，不限定团队再开分支进行开发。

约定：

从develop到master的merge操作后，必须要有tag标记。如 v1.0 v1.0.fix1。本操作为JENKINS持续集成平台来完成，无需人工参与 团队非leader不用过分关注

3、特定差异化项目

视具体项目情况、需求情况启用feature、release、hotfix分支

app-api，线上多版本发布运行：

1. 开启release分支：多个release"较长"生命周期的分支与线上tomcat相应版本相对应，相关bugfix,hotfix及该版本的后续调整在上面进行，JENKINS持续集成平台将直接怼接release分支进行线上发布。
2. 团队成员要求：会切换分支、对分支的fix类改动要merge到develop开发主线上来。
3. 开分支bat/shell脚本准备：

六、CI-pre

1、机器配备

xen+ubt1604+docker

2、玩法规则、不同则不同端区分对待、百花齐放

master-slave多机构建

All：

单元测试、Mock测试?

java后端：

公用jar包构建发布于nexus，独立运行模块assembly打包为xxx.tar.gz用于发布，tomcat项目打包成war包用于发布。 oceans app-api app-site, ts/arm ... arch_common/supply

前端：

代码构建压缩生成 输出于nginxStatic目录

app端：

Anz：产物apk证书签名打包 IOS：linux下可为?

3、java类项目实施准备

构建环境标准化、与Maven构建工具的结合、与线上平台的结合、与单元测试/集成测试用例的结合、与SonarQube源代码质量管理的结合、

设计要求

三方lib包增量/缓存发布、多机多实例发布 发布回滚、buildTestEnv, tag, deplog三条流水线。

build：拉develop发到testEnv tag: inMaster merge develop, tag deploy: 发布线上(机器清单)

设计交互图

标准化运行时

jdk180_162, maven353, tomcat8?..

发布类型

tomcat应用 pvd应用 (jar应用)

CI适配-代码层

maven-profile多环境 (app-api pom工程改造) 分布式配置中心 ctrip-apollo

CI适配-部署层

1. supervisord + tomcat配置文件
2. pvd 标准启停脚本、multiInstance