哈嘿！

前言

在 上文 中我简单概括了矩阵的基本运算，并给出了两个应用实例。这篇文章我们继续谈谈向量。

向量是线性代数中的基本概念，也是机器学习的基础数据表示形式。例如计算机阅读文本的过程首先就会将文本分词，然后用向量表示^[1]。这是因为向量很适合在高维空间中表达和处理。在机器学习中会接触到的诸如投影、降维的概念，都是在向量的基础上做的。

前言

机器学习如火如荼，要学习机器学习，数学基础少不了。所以本系列将对机器学习所用到的线性代数、微积分和概率统计的基础知识做一个简单的概括。

本文将总结线性代数中矩阵的基本知识点。同时理论结合实践，使用 Python 来进行实践。如果需要跟着进行编程实践，请先确保下列环境已安装：

• Python - 编程实践所使用的语言；
• Numpy - Python 的数值计算库。

矩阵（Matrix）是人为约定的一种数据的表示方法，在图像处理、人工智能等领域，使用矩阵来表示和处理数据非常常见。

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

Github-Flow

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

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

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

需求描述

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

主工程持续集成

先说说主工程如何做持续集成。我们使用 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 更新整个项目的代码。最后再执行编译指令。

需求描述

我们尝试使用 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 分支。