你不知道的 Git 使用技巧

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

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

[username].github.io
[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

2. 生成 GPG keys，拿到 [密钥ID]

$ gpg --full-generate-key

3. 输出密钥

$ gpg --list-keys
$ gpg --armor --output public-key.txt --export [密钥ID]

4. 上传 public-key 到 GitHub

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

5. 本地 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 。