Git
Git 实用技巧记录 - 图1

常见企业工作流程

主要介绍，企业中常用的 Git 工作流程！

Git Flow：

  • 主干分支
  • 稳定分支
  • 开发分支
  • 补丁分支
  • 修改分支

Git 实用技巧记录 - 图2

GitHub Flow：

  • 创建分支
  • 添加提交
  • 提交 PR 请求
  • 讨论和评估代码
  • 部署检测
  • 合并代码

Git 实用技巧记录 - 图3

GitLab Flow：

  • 带生产分支
  • 带环境分支
  • 带发布分支

Git 实用技巧记录 - 图4

日常使用最佳实践

总结日常工作中应该遵循的 Git 使用方式和方法！
使用命令行代替图形化界面：

  • 使用命令行来操作，简洁且效率高

提交应该尽可能的表述提交修改内容：

  • 区分 subject 和 body 内容，使用空行隔开
  • subject 一般不超过 50 个字符
  • body 每一行的长度控制在 72 个字符
  • subject 结尾不需要使用句号或者点号结尾
  • body 用来详细解释此次提交具体做了什么

使用 .gitignore 文件来排除无用文件：

  • 可使用模板文件，然后根据项目实际进行修改

基于分支或 fork 的开发模式：

  • 不要直接在主干分支上面进行开发
  • 在新建的分支上进行功能的开发和问题的修复

使用 release 分支和 tag 标记进行版本管理：

  • 使用 release 分支发布代码和版本维护（release/1.32）
  • 使用 tag 来标记版本（A-大 feature 功能；B-小 feature 功能；C-只修 bug）

    常用命令汇总整理

    日常使用只要记住 6 个命令就可以了。
    Git 实用技巧记录 - 图5 ```bash

    工作区 -> 暂存区

    $ git add

暂存区 -> 本地仓库

$ git commit -m “some info”

本地仓库 -> 远程仓库

$ git push origin master # 本地 master 分支推送到远程 origin 仓库

工作区 <- 暂存区

$ git checkout — # 暂存区文件内容覆盖工作区文件内容

暂存区 <- 本地仓库

$ git reset HEAD # 本地仓库文件内容覆盖暂存区文件内容

本地仓库 <- 远程仓库

$ git clone # 克隆远程仓库 $ git fetch upstream master # 拉取远程代码到本地但不应用在当前分支 $ git pull upstream master # 拉取远程代码到本地但应用在当前分支 $ git pull —rebase upstream master # 如果平时使用 rebase 合并代码则加上

工作区 <- 本地仓库

$ git reset # 本地仓库覆盖到工作区（保存回退文件内容修改） $ git reset —mixed # 本地仓库覆盖到工作区（保存回退文件内容修改） $ git reset —soft # 本地仓库覆盖到工作区（保留修改并加到暂存区） $ git reset —hard # 本地仓库覆盖到工作区（不保留修改直接删除掉)

  1. <a name="kiJPC"></a>
  2. ## 配置实用参数选项
  3. 虽然配置比较简单，但是非常有用！
  4. <a name="gY8rZ"></a>
  5. ### 全局配置
  6. ```bash
  7. # 用户信息
  8. $ git config --global user.name "your_name"
  9. $ git config --global user.email "your_email"
  11. # 文本编辑器
  12. $ git config --global core.editor "nvim"
  14. # 分页器
  15. $ git config --global core.pager "more"
  17. # 别名
  18. $ git config --global alias.gs "git status"
  20. # 纠错
  21. $ git config --global help.autocorrect 1

个人配置

  1. # 不加 --global 参数的话，则为个人配置
  2. $ git config --list
  3. $ git config user.name
  4. $ git config user.name "your_name"
  6. # 如果在项目中设置，则保存在 .git/config文件里面
  7. $ cat .git/config
  8. [user]
  9.     name = "your_name"
  10. ......

合并和变基的选择

到底什么时候使用 merge 操作，什么时候使用 rebase 操作呢？

使用 merge 操作 - Python 中的 Requests 库在使用

支持使用 merge 的开发者，他们认为仓库的提交历史就是记录实际发生过什么，它是针对于历史的一个文档，本身其实是有价值的，不应该随意修改。改变历史的话，就相当于使用“谎言”来掩盖实际发生过的事情，而这些痕迹是应该被保留的。可能，这样并不是很好。

  1. # 3rd 的两个分支的 commit 修改相同内容
  2. *   62a322d - (HEAD->master) Merge branch 'hotfix3' into master
  3. |\
  4. | * 6fa8f4a - (hotfix3) 3rd commit in hotfix3
  5. * | 548d681 - 3rd commit in master
  6. |/
  7. * 6ba4a08 - 2nd commit
  8. * 22afcc1 - 1st commit

使用 rebase 操作 - Python 中的 Django 库在使用

支持使用 rebase 的开发者，他们认为提交历史是项目过程中发生过的事情，需要项目的主干非常的干净。而使用 merge 操作会生成一个 merge 的 commit 对象，让提交历史多了一些非常多余的内容。
当后期使用 log 命令参看提交历史的话，会发现主干的提交历史非常的尴尬。比如，同样的修改内容重复提交了两次，这显然是分支合并导致的问题。

  1. # 3rd 的两个分支的 commit 修改相同内容
  2. * 697167e - (HEAD -> master, hotfix) 3rd commit
  3. * 6ba4a08 - 2nd commit (2 minutes ago)
  4. * 22afcc1 - 1st commit (3 minutes ago)

两者的使用原则

总的原则就是，只对尚未推送或分享给其他人的本地修改执行变基操作清理历史，从不对已经推送到仓库的提交记录执行变基操作，这样，才可能享受到两种方式带来的便利。

更新仓库提交历史

Git 提供了一些工具，可以完善版本库中的提交内容，比如：

合并多个 commit 提交记录

日常开发中，为了完成一个功能或者特性，提交很多个 commit 记录。但是在最后，提交 PR 之前，一般情况下，是应该整理下这些提交记录的。有些 commit 需要合并起来，或者需要将其删除掉，等等。

  1. # 调整最近五次的提交记录
  2. $ git rebase -i HEAD~5
  3. $ git rebase -i 5af4zd35  # 往前第六次的commit值
  4. reword c2aeb6e 3rd commit
  5. squash 25a3122 4th commit
  6. pick 5d36f1d 5th commit
  7. fixup bd5d32f 6th commit
  8. drop 581e96d 7th commit
  10. # 查看提交历史记录
  11. $ git log
  12. * ce813eb - (HEAD -> master) 5th commit
  13. * aa2f043 - 3rd commit -> modified
  14. * 6c5418f - 2nd commit
  15. * c8f7dea - 1st commit
编号 选项列表 对应含义解释
1 p/pick 使用这个 commit 记录
2 r/reword 使用这个 commit 记录；并且修改提交信息
3 e/edit 使用这个 commit 记录；rebase 时会暂停允许你修改这个 commit
4 s/squash 使用这个 commit 记录；会将当前 commit 与上一个 commit 合并
5 f/fixup 与 squash 选项相同；但不会保存当前 commit 的提交信息
6 x/exec 执行其他 shell 命令
7 d/drop 移除这个 commit 记录

删除意外调试的测试代码

有时候提交之后，才发现提交的历史记录中存在这一些问题，而这个时候又不想新生成一个 commit 记录，且达到一个修改的目录。即，修改之前的 commit 提交记录。

  1. # 不使用分页器
  2. $ git --no-pager log --oneline -1
  3. d5e96d9 (HEAD -> master) say file
  5. # 改变提交信息并加入暂存区
  6. $ echo "hello" > say.txt
  7. $ git add -u
  9. # 改变当前最新一次提交记录
  10. $ git commit --amend
  11. # 改变且息不改变提交信
  12. $ git commit --amend --no-edit
  13. # 改变当前最新一次提交记录并修改信息
  14. $ git commit --amend -m "some_info"
  16. # 不使用分页器
  17. $ git --no-pager log --oneline -1
  18. 9e1e0eb (HEAD -> master) say file

取消多个 commit 中的部分提交

开发了一个功能，而在上线的时候，产品经理说这个功能的部分特性已经不需要了，即相关特性的提交记录和内容就可以忽略/删除掉了。

  1. # 回滚操作(可多次执行回滚操作)
  2. # 彻底上次提交记录；也可是 PR 的提交记录
  3. # 默认会生成一个类型为 reverts 的新 commit 对象
  4. $ git revert 3zj5sldl

合并某些特定的 commit 提交

不希望合并整个分支，而是需要合并该分支的某些提交记录就可以了。

  1. # 摘樱桃
  2. $ git cherry-pick -x z562e23d

使用引用日志记录

如何找回丢失的内容和记录？
之前说过，使用下面命令回退内容、强制推送代码、删除本地分支，都是非常危险的操作，因为重置之后就没有办法在找到之前的修改内容了。

  1. # 回退
  2. $ git reset --hard <commit>
  4. # 推送
  5. $ git push origin master -f
  7. # 分支
  8. $ git branch -D <branch_name>

其实 Git 留了一个后门，就是使用 relflog 命令来找回之前的内容，只不过是相对来说麻烦一些。而原理也很简答，就是在使用 Git 命令操作仓库的时候，Git 偷偷地把所有的操作记录了下来。

  1. # 查看日志记录
  2. $ git --no-pager log --oneline -1
  3. 4bc8703 (HEAD -> master) hhhh
  5. # 回退到上次提交
  6. $ git reset --hard HEAD~1
  8. # 查看引用日志记录
  9. $ git reflog
  10. 6a89f1b (HEAD -> master) HEAD@{0}: reset: moving to HEAD~1
  11. 4bc8703 HEAD@{1}: commit (amend): hhhh
  13. # 找回内容
  14. $ git cherry-pick 4bc8703

批量修改历史提交

批量修改历史提交虽然不常用，但是理解的话可以省下很多时间！
之前学习到的命令都是针对于一个或者多个 commit 提交信息进行修改的，如果需要全局修改历史提交呢？当然，Git 中也是支持全局修改历史提交的，比如全局修改邮箱地址，或者将一个文件从全局历史中删除或修改。

  • 开源项目中使用了公司邮箱进行提交了
  • 提交文件中包含隐私性的密码相关信息
  • 提交时将大文件提交到了仓库代码中了

这里可以使用 filter-brach 的方式进行修改，但是建议在使用之前，新建一个分支，在上面进行测试没有问题之后，再在主干上操作，防止出现问题，背个大锅在身上。

  1. # 创建分支
  2. $ git branch -b testing
  4. # 修改邮箱地址
  5. $ git filter-branch --commit-filter '
  6.     if [ "$GIT_AUTHOR_EMAIL" == "escape@escapelife.site" ]; then
  7.         GIT_AUTHOR_NAME="escape";
  8.         GIT_AUTHOR_EMAIL="escape@gmail.com";
  9.         git commit-tree "$@"
  10.     else
  11.         git commit-tree "$@"
  12.     fi' HEAD

灵活使用钩子函数

主要介绍.git/hooks 目录下面的示例钩子函数！
在 Git 里面有两类，分别对应客户端和服务端钩子函数。客户端的钩子函数，是在执行提交和合并之类的操作时调用的。而服务端钩子函数，就是当服务端收到代码提交之后，可以出发代码检查和持续集成的步骤。作为开发者并不会搭建 Git 服务器，所以基本不会涉及。
下面就是 Git 自带的钩子脚本，但是自带的都 .sample 作为后缀，表示并没有启用，表示为一个示例。如果需要启用的话，将 .sample 作为后缀删除掉，即可。而其钩子脚本的对应内容，都是使用 Shell 语法进行编写的。

  1. ➜ ll .git/hooks
  2. total 112
  3. -rwxr-xr-x  applypatch-msg.sample
  4. -rwxr-xr-x  commit-msg.sample
  5. -rwxr-xr-x  fsmonitor-watchman.sample
  6. -rwxr-xr-x  post-update.sample
  7. -rwxr-xr-x  pre-applypatch.sample
  8. -rwxr-xr-x  pre-commit.sample
  9. -rwxr-xr-x  pre-merge-commit.sample
  10. -rwxr-xr-x  pre-push.sample  # 不会推送包含WIP的commit提交
  11. -rwxr-xr-x  pre-rebase.sample
  12. -rwxr-xr-x  pre-receive.sample
  13. -rwxr-xr-x  prepare-commit-msg.sample
  14. -rwxr-xr-x  update.sample

其实，钩子脚本使用任何语言编写都是可以的，只要让程序返回对应的退出码就可以了。
正常的代码合入流程就是，本地修改之后，提一个 PR 请求并通过 Github 的 CI 检查，接下来进行代码评审，最后被合并入主干。但是，好的一个习惯就是，在代码提交之前就应该保证代码不会出现语法错误等基础问题，比如通过 flake8 和 PEP8 标准等。
这个时候就可以使用 pre-commit 这个 GitHub 的开源项目了，其本质就是给项目添加钩子函数的一个脚本，可以保证在提交代码或者推送代码之前，先检查代码的质量。
而 pre-commit-hooks 这个项目里面包含的就是，现在所支持的钩子脚本，即开箱即用的钩子脚本集合。而其钩子脚本的对应内容，都是使用 Python 语法进行编写的。

  1. # 安装方式
  2. $ pip install pre-commit
  4. # 指定 hook 类型（即在哪里检查）
  5. $ pre-commit install -f --hook-type pre-push
  7. # 配置需要执行的检查
  8. $ cat .pre-commit-config.yaml
  9. repos:
  10. - repo: https://github.com/pre-commit/pre-commit-hooks
  11.   rev: v2.9.2
  12.   hooks:
  13.     - id: trailing-whitespace
  14.     - id: flake8
  16. # 执行 push 操作时检查
  17. $ git push origin master

快速克隆大型项目

在大项目中工作中，拉取代码非常占时间！
如果想为 Linux 或 Python 这样的大型项目贡献提交的时候，首先遇到的问题就是，如果快速的 clone 该项目到本地。因为改项目提交历史超多且仓库巨大，加了国内网络的问题，可能等项目完全拉下来的时候，热情都消减下去了。
好在 Git 也想到了这样的问题，可以使用 --depth 参数值拉取远程仓库上面最新一次的提交历史，并不包含项目历史记录，即 .git/objects/ 目录下的对象只是本地的，并不包含之前的多次修改产生的对象。

  1. # 克隆不包含之前历史
  2. $ git clone http://xxx.xx.xxx/xxx --depth=1

但是，有时间可能会需要 clone 仓库中的某个 tag 版本对应下的内容。如果直接使用 clone 命令是无法做到的，需要执行如下操作，即可完美解决。

  1. # 克隆特定版本代码
  2. $ git init xxx-15-0-1
  3. $ git remote add origin http://xxx.xx.xxx/xxx
  4. $ git -c protocol.version=2 fetch origin 15.0.1 --depth=1
  5. $ git checkout FETCH_HEAD

上面的效果已经基本可以满足日常使用需求了，但是不幸的是，现在接受了一个机器学习的项目，里面包含了大量的 lfs 文件，现在 clone 又会变得非常慢。可以使用如下操作来避免，Git 工具主动拉去 lfs 文件，来达到目录。

  1. # 克隆不包含 LFS 数据
  2. $ GIT_LFS_SKIP_SMUDGE=1 git clone http://xxx.xx.xxx/xxx

如何处理工作中断

如果在多路运转的时候，还能够高效的进行开发！
比如，现在正在一个分支为项目添加一个小的功能，此时，产品经理说是线上环境现在有一个 bug 需要来修复下。但是，此时添加的小功能并没有完成。
如果此时，直接切换到主干分支的话，会将之前分支没有来得及提交的内容全部都带到了主干分支上来，这是不想看到的情况。此时，需要保存上个分支的工作状态，在修改完成线上 bug 之后，再继续工作。
好在 Git 也想到了这样的问题，可以使用 stash 子命令将当前工作区、暂存区当中的修改都保存到堆栈之中。等到需要处理的时候，再弹出堆栈中的内容，再次进行开发。

  1. ➜ git stash -h
  2. usage: git stash list [<options>]
  3.    or: git stash show [<options>] [<stash>]
  4.    or: git stash drop [-q|--quiet] [<stash>]
  5.    or: git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
  6.    or: git stash branch <branchname> [<stash>]
  7.    or: git stash clear
  8.    or: git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
  9.           [-u|--include-untracked] [-a|--all] [-m|--message <message>]
  10.           [--pathspec-from-file=<file> [--pathspec-file-nul]]
  11.           [--] [<pathspec>...]]
  12.    or: git stash save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
  13.           [-u|--include-untracked] [-a|--all] [<message>]
  15. # 存储当前的修改但不用提交 commit
  16. $ git stash
  18. # 保存当前状态包括 untracked 的文件
  19. $ git stash -u
  21. # 展示所有 stashes 信息
  22. $ git stash list
  24. # 回到某个 stash 状态
  25. $ git stash apply <stash@{n}>
  27. # 删除储藏区
  28. $ git stash drop <stash@{n}>
  30. # 回到最后一个 stash 的状态并删除这个 stash 信息
  31. $ git stash pop
  33. # 删除所有的 stash 信息
  34. $ git stash clear
  36. # 从 stash 中拿出某个文件的修改
  37. $ git checkout <stash@{n}> -- <file-path>

其实比较保险的做法就是，将当前的所有修改进行 push 并保存到远程仓库里面。这样的好处在于，可以远端备份修改，不会害怕本地文件丢失等问题。等到需要继续开发的时候，拉下对应内容，再想办法进行补救，比如使用 --amend 或者 reset 命令。

  1. # 将工作区和暂存区覆盖最近一次提交
  2. $ git commit --amend
  3. $ git commit --amend -m "some_info"
  5. # 回退到指定版本并记录修改内容（--mixed）
  6. # 本地仓库覆盖到工作区（保存回退文件内容修改）
  7. $ git reset a87f328
  8. $ git reset HEAD~
  9. $ git reset HEAD~2
  10. $ git reset <tag>~2
  11. $ git reset --mixed <commit/reference>
  13. # 本地仓库覆盖到工作区（不保留修改直接删除掉）
  14. $ git reset --soft <commit/reference>
  15. # 本地仓库覆盖到工作区（保留修改并加到暂存区）
  16. $ git reset --hard <commit/reference>

相关链接：

  1. https://github.com/pre-commit/pre-commit
  2. https://github.com/pre-commit/pre-commit-hooks