你不知道的 Git 使用技巧

1. Pages 功能

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

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

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

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

2. Git hooks

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

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

1
2
3
4
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 等。

使用时，主要分成两步：

使用 GitHub 账户登陆 TravisCI
在 GitHub 仓库新增 .travis.yml 文件

1
2
3
4
5
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 ：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# 一些前置脚本，完成激活环境等操作
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 主要步骤：

安装 GPG

1
brew install gnupg gnupg2

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

1
gpg --full-generate-key

输出密钥

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

上传 public-key 到 GitHub

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

本地 Git 配置

1
2
git config --global user.signingkey  [密钥ID]
git config --global commit.gpgsign true

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

需要注意的是保持 git config --global user.name 和 git config --global user.email 与上面生成 GPG Key 时一致。

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。

9. Git 分支的目录管理

Git 的分支就是在 .git/refs/heads 目录下的一个文件，文件内容指向某一条 Git 记录。

在实践主干集成、分支开发的过程中，通常会产生大量分支。使用目录可以很好地对 Git 分支进行管理。目录分支与普通的分支一样，只不过分支名带了目录分割符 / 。

1
2
3
4
5
6
7
8
git branch

*bugfix/1/1
feature/2/1
hotfix/3/1
release/4/1
custom/5/1
master

在有些 Git 工具中，可以以目录的形式展示分支，例如：SourceTree、BitBucket 。