图片管理一期概述
以组件的维度，图片和组件之间建立一对一关系，在打包的时候或者本地开发执行脚本的时候动态拉图图片，这些图片在服务端进行去重，以zip包的形式下载到本地，用脚本将本地的图片打成xcasset包导入到工程中，从而实现服务端管理app图片的能力。这样做的好处是图片的大小、是否缺图、增删操作等数据都可以拿到，后续还可以对未使用过的图片进行云控处理
如何处理分支关系
问题
组件A在多人同时开发的情况下，从A拉出俩开发分支featureM、featureN，featureM添加一个图片m1，featureN移除一个图片m2，当featureM合并之后组件多了一个图片m1,featureN也有这个关系就会包含俩图片（m1,m2）,这样就有问题了，因为featureN并没有合并，还在开发中，不应该有图片m1.
这就涉及到同一个组件分支和图片的对应关系的问题了
图片和组件的关联关系，应该是图片和组件的分支或者版本号关联，同一个组件，不同分支不同版本号所关联的图片都应该是独立的。
处理问题的方案
gitlab中的代码仓库加上hook，当有人push代码的时候就能监听到，每个公司应该都有自己的分支管理方案，我们是分支合并的时候必须merge request，这样服务端能拿到hook事件，触发分析merge操作，获取到源分支和目标分支以及提交人信息。这时候需要把源分支的图片关系合并到目标分支。图片的绑定关系应该是和组件的版本号或者分支一一对应的
图片同步方案
1、分支创建和push方式合并代码的逻辑梳理 （1）创建分支触发push事件(feature分支和release分支创建时的图片依赖关系的初始化)；
（2）当通过push的方式将代码合并到develop，release或者master分支时，图片依赖关系的同步；
风险点1：基于master创建分支时，图片组件依赖关系为develop分支的依赖关系；（需要保证没有只合并了master，但是没有同步到develop的需求）
风险点2：直接通过push方式（没有通过mr合并）合并develop，release，master，需要保证commit信息中包含：【分支名称】标签
2、mr方式合并代码逻辑梳理
3、定时任务更新图片组件依赖关系流程梳理
4、图片组件依赖关系同步的具体执行逻辑
5、监控方案
6、结论总结 6.1 创建分支时，图片组件依赖关系会从develop分支同步到新分支 6.2 feature之间的图片组件依赖关系需要研发人员手动创建同步任务进行同步 6.3 feature到develop分支，release分支，master分支的图片组件依赖关系同步，需要借助于webhook，自动进行同步。 （1）push 事件的webhook需要借助【分支名】标签，获取源分支名称 （2）mr的webhook可以通过参数拿到明确的源分支和目标分支 6.4 风险： （1）组件webhook缺失
5.解决办法 （1）监控并自动补充webook
（2）避免使用push方式合并develop，release，master分支代码（回收所有人的权限，并设置为保护分支）
总结
本期分享的是服务端处理方案逻辑，下期我们分享iOS客户端的实现逻辑 后期我们会对资源管理系统进行继续详细分享
自如大前端研发中心招募新同学！ FE/IOS/Android工程师看过来
公司福利有： 全额五险一金，并额外购买商业保险 免费健身房+年度体检 公司附近租房9折优惠 每年2次晋升机会
办公地点：北京酒仙桥普天实业科技园 欢迎对技术有执着热爱的你加入我们！简历请投递 [email protected]！