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打包为⽤于发布，tomcat项⽬打包成war包⽤于发布。 oceans app-api app-site, ts/arm ... arch_common/supply
前端：
代码构建压缩⽣成输出于nginxStatic⽬录
app端：
Anz：产物apk证书签名打包 IOS：linux下可为?
3、java类项⽬实施准备
构建环境标准化、与Maven构建⼯具的结合、与线上平台的结合、与单元测试/集成测试⽤例的结合、与Sonar Qube源代码质量管理的结合、
设计要求
三⽅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

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。