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

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

    Github-Flow

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

    Github-Flow

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

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

Apr 21 2016
化繁为简的企业级 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

Apr 13 2016
化繁为简的企业级 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

© 2017 Joseph Pan with help from Hexo and .