目录

    1. Pages 功能

    GitHub、GitLab、Bitbucket 等,都提供了免费的静态页面托管服务,称之为 Pages 。利用 Pages 服务,可以发布文档、博客等。

    以 GitHub 为例,通常只需要简单几个步骤,就可以使用 Pages:

    1. 新建一个项目:[username].github.io
    2. 提交静态 html 文件
    3. 访问 [username].github.io,也可以绑定自己的域名进行访问。

    如果你想要使用 Markdown 编辑文档,那么就需要借助 Jekyll、Hexo 等静态页面生成工具。

    2. Git hooks

    Git hooks 是 Git 仓库在特定事件被触发时,自动执行的一系列脚本。通过关联特定的事件,可以达到自定义工作流的目的。

    Git 将 hooks 脚本存储在仓库的 .git/hooks 目录下。

    $ ls .git/hooks/
    applypatch-msg.sample        post-update.sample        pre-push.sample            prepare-commit-msg.sample
    commit-msg.sample        pre-applypatch.sample        pre-rebase.sample        update.sample
    fsmonitor-watchman.sample    pre-commit.sample        pre-receive.sample
    

    钩子分为客户端和服务器端。客户端关联本地事件,服务器端关联服务器事件。

    客户端的钩子有:

    • pre-commit,在提交信息前运行。推荐一个工具,提供了大量相关插件,pre-commit
    • prepare-commit-msg,在启动提交信息编辑器之前,默认信息被创建之后运行。
    • post-commit,在整个提交过程完成后运行。
    • applypatch-msg,可以用该脚本来确保提交信息符合格式,或直接用脚本修正格式错误。
    • pre-applypatch,在 git am 运行期间被调用。
    • post-applypatch,运行于提交产生之后,是在 git am 运行期间最后被调用的钩子。
    • pre-rebase,运行于变基之前,以非零值退出可以中止变基的过程。
    • post-rewrite,被那些会替换提交记录的命令调用。
    • post-checkout,在 git checkout 成功运行后调用。
    • post-merge,在 git merge 成功运行后调用。
    • pre-push,在 git push 运行期间, 更新了远程引用但尚未传送对象时被调用。
    • pre-auto-gc,会在垃圾回收开始之前被调用,可以用它来提醒你现在要回收垃圾了,或者依情形判断是否要中断回收。

    服务器端的钩子有:

    • pre-receive,处理来自客户端的推送操作时,被调用。
    • update,为每一个准备更新的分支各运行一次。
    • post-receive,在整个过程完结以后运行,可以用来更新其他系统服务或者通知用户。

    另外,通常 Git 仓库页面上,可以注册回调 URL hooks,用于触发某些事件,比如 Jenkins 的流水线。

    3. CI/CD

    除了上面提到的 Git hooks,还可以通过 yaml 更灵活地定义 CI/CD 流程。而你只需要理解 stage、job 等 CI/CD 概念,编写简单的 shell。

    更多相关内容,可以参考 常用的一些 CI 脚本

    3.1 GitHub CI

    Travis CI 是一个基于云的持续集成项目,目前已经支持大部分主流语言,如:C、PHP、Ruby、Python、Nodejs、Java、Objective-C 等。

    使用时,主要分成两步:

    1. 使用 GitHub 账户登陆 TravisCI
    2. 在 GitHub 仓库新增 .travis.yml 文件
    language: node_js
    node_js:
      - '7.5.0'
    before_script: npm install
    script: npm run dev
    

    3.2 GitLab CI

    Gitlab Runner 是 GitLab 提供的 CI 执行器。GitLab 官方提供了限时长的免费 Runner,也允许用户自助接入服务器作为项目的 Runner。

    使用时,不需要借助第三方,直接在仓库中增加 .gitlab-ci.yml

    # 一些前置脚本,完成激活环境等操作
    before_script:
      - source /data/runner/node/bin/activate
      - which node && node --version
      - which npm && npm --version
      - LANG="zh_CN.utf8"
      - export LC_ALL=zh_CN.UTF-8
    
    # 编排需要执行的 stage
    stages:
      - build
      - deploy
    

    更多相关内容,可以参考 GitLab CI 配置 Runner

    4. GPG 验证提交

    Git 是一个分布式的版本管理系统。每个人都有一份仓库的副本,每个人都在自己的分支上开发,然后合并到主分支。这样可能会导致某些恶意提交,原因可能是某位开发者的账号被盗、服务器漏洞等。

    人与人之间的信任,需要传导到仓库之间。因此,我们需要 GPG,一种信息加密、验证机制。

    GitHub 上使用 GPG 主要步骤:

    1. 安装 GPG
    $ brew install gnupg gnupg2
    
    1. 生成 GPG keys,拿到 [密钥ID]
    $ gpg --full-generate-key
    
    1. 输出密钥
    $ gpg --list-keys
    $ gpg --armor --output public-key.txt --export [密钥ID]
    
    1. 上传 public-key 到 GitHub

    在 Settings 页面,点击 SSH and GPG keys,在 GPG keys 那里,点击 New GPG key。在输入框里填入 public-key.txt 内容,保存即可。

    1. 本地 Git 配置
    $ git config --global user.signingkey  [密钥ID]
    $ git config --global commit.gpgsign true
    

    配置完毕,以后提交代码时,每条提交记录都会显示一个绿色的 Verified 标签。

    5. Git 工作流

    通过 Git 对项目进行分支开发,建立的工作流程称之为 Git Flow。 Git 主要有三种工作流:

    • Git flow

    长期存在两个分支:主分支 master 和 开发分支 develop。适合发布流程比较长的项目,比如 Apple App Store 应用。

    • GitHub flow

    只有一个长期存在的 master 主分支。适合持续集成,更新迭代快的项目,典型的互联网项目特征。

    • GitLab flow

    Git flow 和 GitHub flow 的结合体。采用上游优先的原则,master(上游)修改的代码会同步到其他分支(下游),比如 chromium 开发,不同开发商在不同分支开发,但是服务商会不定期合并 master 代码。

    更多相关内容,可以参考 敏捷开发之研发流程

    6. Merge/Pull Request

    在采用了 Git 工作流之后,需要采用 Merge/Pull Request 的方式进行多人开发。

    通常,我们会在 Merge/Pull Request 流程中做 Code Review。Merge/Pull Request 流程是保证模块正确耦合、高质量代码的关键。

    另外,Merge/Pull Request 还可以关联 issues,例如: close #33,当 Merge/Pull Request 被 Merge 时,相应的 issues 就会被自动关闭。

    更多相关内容,可以参考 基于 Git 的前后端开发工作流如何更好做 CodeReview

    7. 使用 issues 进行项目管理

    除了管理代码仓库版本,Git 中的 issues 还可以用于项目管理。

    issues 指的是一项待完成的工作,可以是缺陷、功能建议、规划中的功能等。

    issues 只是列出了一系列工作事项,Git 提供了 label、milestone、board 对 issues 进行多维度的管理功能。

    label 主要用于对 issues 分类、过滤。

    milestone 主要用于定制计划,一个 issues 只能绑定一个milestone。

    board 提供的看板功能,可以直观看到工作事项、项目进度。

    更多相关内容,可以参考 如何使用 python-gitlab 自动创建 GitLab Label

    8. 定制 issues 或者 pull request 模板

    在使用 issues 对项目进行管理时,规范化 issues 模板,让提交者尽可能准确描述问题,是十分有必要的。

    Git 提供这样的模板功能。

    以 GitHub 为例,在代码仓库新建目录:.github。你可以添加单个模板,也可以添加多个模板。

    • 添加单模板

    .github 目录下添加 ISSUE_TEMPLATE.md 文件作为 issues 默认模版。

    • 添加多模板

    在代码仓库新建目录:.github/ISSUE_TEMPLATE。该目录下可添加多个 .md 文件作为 issues 模版。

    pull request 模版 和 issues 模板类似,只是文件或文件夹名称改为了 PULL_REQUEST_TEMPLATE