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

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

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

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

Framework SDK
Framework SDK

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

Read More

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

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

需求描述

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

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

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

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

Read More

2016-04-29
化繁为简的企业级 Git 管理实战(三):分支管理策略

说到版本控制,就不得不提到分支管理策略。就像学开车必须学学交通规则。分支管理策略是代码版本控制的基础组成部分。为团队定制一套合适的分支管理策略,就好比制定了一套合理的交通规则,可以让团队的代码的更加有序地演进,尽可能降低多分支带来的复杂度,并避免由于分支混乱引发的各种“车祸”。本文将简单讨论下我们在开发过程中尝试的各种分支管理策略,在面对各种复杂场景下呈现的优势与不足,以及我们的妥协和后续期望。

Github-Flow

作为 Github 的重度用户,我首先考虑的当然是 Github-Flow

Github-Flow
Github-Flow

Github-Flow 是一种非常简单的分支管理方案。它的流程只有如下几步:

  1. 拉出一个新分支;
  2. 在新分支上进行修改,并提交和推送你的改动;
  3. 发起一个 Pull Request ,向代码管理员申请将你提交的分支合并到原来的分支;
  4. 讨论并接受 Code Review。在这个过程中,你依然可以继续推送新的代码到你的开发分支上,并且新的提交在推送后会出现在未完成合并的 Pull Request 页面中;
  5. 合并和发布。Review 通过后,代码管理员将该分支合并到原来的主分支上。
Read More

2016-04-21
化繁为简的企业级 Git 管理实战(二):多分支子模块持续集成

化繁为简的企业级 Git 管理实战(二):多分支子模块持续集成

需求描述

上一篇文章 中,我简单描述了我们一个项目的复杂程度:子模块、嵌套子模块、多分支。除了工程分支切换上的复杂,我们还遇到另一个问题:子模块持续集成。

主工程持续集成

先说说主工程如何做持续集成。我们使用 Gitlab 自带的 Gitlab-Ci 作为我们的持续集成系统。Android 端的主工程的持续集成脚本如下:

1
2
3
4
5
6
7
8
build:
tags:
- android
script:
- ./fmanager checkout -f $CI_BUILD_REF_NAME
- ./fmanager update
- gradle clean
- gradle aR

其中, CI_BUILD_REF_NAME 指定要编译哪个分支的主工程。当我们推送代码到某个分支时,该分支下的持续集成脚本就会被调用,CI_BUILD_REF_NAME 变量就会是那个分支的名字。在执行构建前,先用 fmanager 完成主工程和所有模块的分支切换 ,之后再用 fmanager 更新整个项目的代码。最后再执行编译指令。

Read More

2016-04-13
化繁为简的企业级 Git 管理实践(一):多分支子模块依赖管理

化繁为简的企业级 Git 管理实践(一):多分支子模块依赖管理

需求描述

我们尝试使用 Git 来维护一个项目的代码。这个项目的结构比较复杂:

  • 项目包含由多个子模块,每个子模块是一个独立的 Git 仓库,子模块还允许继续嵌套包含子模块。 例如,主工程依赖 common、framework、react_native 等多个子模块,而 react_native 子模块又依赖 node_modules、HFCommon、HFModules 等多个嵌套子模块。
1
2
3
4
5
6
7
8
9
10
11
[-] app_android/
|-[+] HFUIKit
|-[+] channel
|-[+] common
|-[+] framework
|-[+] hybrid
|-[+] messagecenter
|-[-] react_native
|-[+] HFCommon
|-[+] HFModules
|-[+] node_modules
  • 主工程和子模块允许存在多个分支,且相互之间有依赖关系。例如,主工程的 jilin 分支同时依赖 common 子模块的 master 分支,以及 framework 子模块的 jilin 分支。
Read More

© 2021 wzpan