Please enable Javascript to view the contents

你不知道的 Git 使用技巧

 ·  ☕ 6 分钟

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 目录下。

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 等。

使用时,主要分成两步:

  1. 使用 GitHub 账户登陆 TravisCI
  2. 在 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 主要步骤:

  1. 安装 GPG
1
brew install gnupg gnupg2
  1. 生成 GPG keys,拿到 [密钥ID]
1
gpg --full-generate-key
  1. 输出密钥
1
2
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 配置
1
2
git config --global user.signingkey  [密钥ID]
git config --global commit.gpgsign true

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

需要注意的是保持 git config --global user.namegit 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 。


微信公众号
作者
微信公众号