发布系统Git使用指南 - the Git Way to Use Git

发布系统Git使用指南

——the Git Way to Use Git

背景

​ 有文章曾归纳,Git是一套内容寻址文件系统,意思是,Git的核心是存储键值对^[1]^。显然,这样的形式不利于普通人类使用。

       通常情况下我们使用的Git命令,都被称作高级命令(例如pull、merge等),区别于底层的低级命令,两种命令分别对应于Git文档中出现Porcelain、Plumbing(第一次在文档见到这些词有没有很困惑!)。

       高级命令大都有易读参数与翔实输出,可以认为是由低级命令封装,方便人使用。那么低级命令存在的意义是?

       根据文档的描述^[2]^,低级命令的接口相较高级命令,更加稳定。低级指令本身就是为脚本使用而存在的,便于确切的输入参数并精准的识别输出。那么,在发布系统中合理使用低级命令替代高级命令,无疑将会使设计的逻辑更加准确的执行。

       以下,根据工作中发布系统的实际场景和经验,从两个方面总结一下如何利用更恰当的Git命令,实现较完备的代码操作流程。

获取代码

       代码获取的大致逻辑分为四个层级:确定仓库、确定分支、确定Commit ID、确定目录

仓库

       确定仓库地址之前,首先需要当前工作目录是否是一个Git仓库

chentairan@localhost ~/t/git-learn> git rev-parse --is-inside-work-tree
true

​ 确认当前工作目录的仓库地址

chentairan@localhost ~/t/git-learn> git config --list|grep -F "remote.origin.url"
remote.origin.url=ssh://git@gitlab.xxx/chentairan/git-learn.git

​ 如果需要直接设置仓库地址

chentairan@localhost ~/t/git-learn> git config remote.origin.url ssh://git@gitlab.xxx/chentairan/git-learn.git

分支

​ 获取指定远程分支

chentairan@localhost ~/t/git-learn> git fetch ssh://git@gitlab.xxx/chentairan/git-learn.git $BRANCH_NAME:refs/remotes/origin/$BRANCH_NAME
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
From ssh://gitlab.xxx/chentairan/git-learn
 * [new branch]      dev        -> origin/dev

​ 获取分支的Commit ID

chentairan@localhost ~/t/git-learn> git rev-parse --verify refs/remotes/origin/$BRANCH_NAME
9e100c01201678286db5d266b8d342b0dd8a8e0d

​ 检出提交

chentairan@localhost ~/t/git-learn> git checkout -f 9e100c01201678286db5d266b8d342b0dd8a8e0d

​ 去掉多余文件

chentairan@localhost ~/t/git-learn> git clean -fdx

多分支集成

​ 在同时有多个RD一起开发的项目中,总会遇到有多个分支需要同时上线的情况(对应多个需求或者同一需求的不同工作部分)。通常的做法是从主干上拉出一个临时分支,将各开发分支的变更全部合并

chentairan@localhost ~/t/git-temp> git fetch origin master:refs/remotes/origin/master $BRANCH_DEV1:refs/remotes/origin/$BRANCH_DEV1 $BRANCH_DEV2:refs/remotes/origin/$BRANCH_DEV2
...
chentairan@localhost ~/t/git-temp> git checkout origin/master
chentairan@localhost ~/t/git-temp> git merge --no-edit --strategy=octopus origin/$BRANCH_DEV1 origin/$BRANCH_DEV2 ...

​ 如果没有冲突,那么多分支的检出就完成了

Commit ID

​ 如果发布时需要检出某指定提交,而不是某分支的最新提交(比如生产环境发布的代码,一定要是测试环境测试通过的代码版本),那么在fetch远程分支之后,直接检出对应提交

chentairan@localhost ~/t/git-temp> git checkout -f $COMMIT_ID

目录

​ 需要集成的项目代码可能不在项目根目录,而在项目下某一目录中,在使用pushd $TARGET_DIRECTORY之后,可能需要检查当前所在目录

chentairan@localhost ~/t/git-temp> pushd target_dir
chentairan@localhost ~/t/git-temp> git rev-parse --show-prefix
target_dir/
chentairan@localhost ~/t/git-temp> popd
chentairan@localhost ~/t/git-temp> git rev-parse --show-prefix

chentairan@localhost ~/t/git-temp> 

本节回顾

git rev-parse用于查看参数,返回结果通常可以直接使用不需额外处理

git config用于配置、查看参数,绕过了git remote命令可能存在的报错

git fetch用于拉取分支,并不改变当前工作区内容,相比git pull更加精确有效

git checkout用于检出提交,但对于缓存区文件(也许上次集成生成的问题)以及.gitignore中配置的文件不做处理

git clean用于清理工作区,仅留下指定提交下面关联的文件

git merge --no-edit --strategy=octopus用于合并多个分支,–no-edit参数使得CommitMessage不需要编辑,octopus是默认的Merge策略,在遇到复杂合并操作,需要人工解决时,拒绝合并

代码基线

​ 基线管理简单说就两件事:确保开发代码包含代码主干的最新提交,确保代码主干有稳定版本可追溯。再说细一点:发布时检查代码是否合并了主干的最新提交,也即是最新的上线代码;线上发布完成之后,代码合并至主干,并打Tag。

检查代码合并主干

​ 检查是否合并了主干最新提交,通常有两种实现方式:一是在开发提交代码时,Git通过Hook配置检查;二是在发布系统这里,发布前做检查。方法一后续会写一篇文章专门讲Hook的能干的事情,本文主要介绍方法二。

​ 查看代码主干位置

chentairan@localhost ~/t/git-temp> git ls-remote origin refs/heads/master
1297bb993557e8b58b37abc3dbb315402f95f349    refs/heads/master

​ 查看开发代码是否包含此次提交历史

chentairan@localhost ~/t/git-temp> git rev-list $COMMIT_ID
......
f19d66e5a154e3b7415b36d55d6cdd9c3648261d
9e100c01201678286db5d266b8d342b0dd8a8e0d
1297bb993557e8b58b37abc3dbb315402f95f349
......

​ 此处可以通过grep检查是否包含主干的最新提交

向主干合并&Tag

​ 由于开发的代码包含了主干的最新提交,那么向主干合并时,只是一个向前走的过程,一定不会有冲突,所以直接使用merge进行合并

...如第一部分拉取发布分支...
chentairan@localhost ~/t/git-temp> git checkout origin/master
chentairan@localhost ~/t/git-temp> git merge $COMMIT_ID --no-ff -m "$SOME_MESSAGE"
chentairan@localhost ~/t/git-temp> git tag $TAG_INFO -m "Create production tag"
chentairan@localhost ~/t/git-temp> git push origin HEAD:refs/heads/master --tags

本节回顾

git ls-remote用于查看远程代码仓库上主干分支的位置

git rev-list用于查看某次提交之前的历史

git merge --no-ff 用于合并代码。根据健康的Git工作流,所有的开发提交合并至主干时都是fast-forward过程。–no-ff参数能使fast-forward也产生一个新的Merge Commit(无此参数则不会),目的是保持开发分支的开发记录,保持整个代码开发历史的完整性

git tag用于新建Tag,保存线上稳定版本

git push origin HEAD:refs/heads/master --tags用于提交Merge后的代码及Tag。使用origin/master拉取代码,并使用HEAD:refs/heads/master方式提交,相比切换至本地master分支再更新、合并、提交,步骤更简单,并绕过本地master分支可能存在的需要处理的变更

提示&总结

​ 发布系统的准确性直接影响线上稳定性,准确性的首要任务是确保异常产物无法上线

​ 所有的命令均可以通过Shell的$?进行判错,有异常一定终止流程,人工介入,尽量避免使用–force参数

​ 所有的命令以准确性为首要目标,脚本中所有的Git指令,能尽可能全面地指定参数,则尽量全面(曾经遇到过使用Git关键字作为分支名,导致的异常问题,Git偶尔会混淆在命令中该参数的具体含义指代。PS:不规范的名字可以在提交前通过Hook进行检查)

参考文献

[1][https://git-scm.com/book/zh/v1/Git-%E5%86%85%E9%83%A8%E5%8E%9F%E7%90%86-Git-%E5%AF%B9%E8%B1%A1](https://git-scm.com/book/zh/v1/Git-%E5%86%85%E9%83%A8%E5%8E%9F%E7%90%86-Git-%E5%AF%B9%E8%B1%A1)

[2] http://man7.org/linux/man-pages/man1/git.1.html

点赞