Apr 19 2017
化繁为简的企业级 Git 管理实战(五):二进制大文件的版本控制

    毫无疑问,Git 非常适合用于代码文件的版本控制。对于纯代码仓库,由于每次实际提交都是增量内容,即使仓库经历了几十次提交,整个仓库的大小往往都不会大幅增加。

    而对于存在二进制文件的仓库,情况就变了:Git 并不能很好地支持二进制文件的增量提交,每次更新一个二进制文件,就相当于把这份文件的完整内容再往仓库里扔。久而久之,这个仓库就会变得非常大,影响代码拉取速度。

    举一个实际的例子,为了加快应用的构建速度,我们团队的框架先会编译成 SDK ,再交由上层构建应用。框架 SDK 也是一个独立的 Git 仓库,里头包含了大量的二进制包:

    Framework SDK

    由于框架也有多个分支,每个分支的迭代速度比较快,SDK 仓库的体积在三个月的时间内就膨胀到了 1G 。

Read More

Apr 12 2017
化繁为简的企业级 Git 管理实战(四):多 Gitlab 数据同步

    化繁为简的企业级 Git 管理实战(四):多 Gitlab 数据同步

    需求描述

    在继续写数学系列前,我想切回去之前的 Git 系列写点东西。我想写系列文章也可以像操作系统的进程调度一样,一个系列暂时写不动了,先 保存现场 跳去另一个 topic 写点东西,同时也给自己留点 buffer 再酝酿一下这个暂时 中断 的系列。等这个系列酝酿够了,再 恢复现场 ,继续还这个系列的技术债。

    对于一个规模较大的企业,存在多个 Gitlab 站点是很常见的事情。

    比如,我们团队在公司发布统一的 Gitlab 之前早已经搭了一个团队用的 Gitlab ,当公司开始推 Git 时,由于我们已经对自己团队的 Gitlab 做了大量的定制,因此并不打算迁移到公司的 Gitlab 。

    自己搭建 Gitlab 的好处是可以随心所欲的进行定制,像加远程钩子之类的东西想加就加。但缺点就是平台的维护成本也落到了自己身上。相比之下,公司 Gitlab 则没有什么维护成本,服务的稳定性由更专业的运维人员保证,也不用考虑扩容的问题,但灵活定制就别想了。如果能够实现 Gitlab 间的数据自动同步,我们可以没有顾忌的使用自己的 Gitlab 平台,一旦出现问题,再无痛迁移到公司的 Gitlab 。这样一方面避免了单点问题,节省了维护成本;另一方面也能尽可能保证灵活可定制。本文想讨论的就是多个 Gitlab 站点间的数据同步问题。

Read More

© 2017 Joseph Pan with help from Hexo and . Hosted by Coding Pages.