一、常见工作流程
① Git Flow
② Github Flow
- 创建分支
- 添加提交
- 提交 PR 请求
- 讨论和评估代码
- 部署检测
- 合并代码
③ Gitlab Flow
二、日常使用最佳实践
- 使用命令行代替图形化界面：使用命令行来操作，简洁且效率高；
- 提交应该尽可能的表述提交修改内容：
-
- 区分 subject 和 body 内容，使用空行隔开；
-
-
-
-
- 使用 .gitignore 文件来排除无用文件：可使用模板文件，然后根据项目实际进行修改；
- 基于分支或 fork 的开发模式：
-
-
- 使用 release 分支和 tag 标记进行版本管理：
-
- 使用 release 分支发布代码和版本维护（release/1.32）；
-
- 使用 tag 来标记版本（A-大 feature 功能；B-小 feature 功能；C-只修 bug）。
三、常用命令
$ git add <file/dir>
$ git commit -m "some info"
$ git push origin master
$ git checkout -- <file>
$ git reset HEAD <file>
$ git clone <git_url>
$ git fetch upstream master
$ git pull upstream master
$ git pull --rebase upstream master
$ git reset <commit>
$ git reset --mixed <commit>
$ git reset --soft <commit>
$ git reset --hard <commit>
四、配置实用参数选项
① 全局配置
$ git config --global user.name "your_name"
$ git config --global user.email "your_email"
$ git config --global core.editor "nvim"
$ git config --global core.pager "more"
$ git config --global alias.gs "git status"
$ git config --global help.autocorrect 1
② 个人配置
$ git config --list
$ git config user.name
$ git config user.name "your_name"
$ cat .git/config
[user]
name = "your_name"
......
五、合并和变基的选择
① 使用 merge 操作 Python 中的 Requests 库使用
- 支持使用 merge 的开发者，认为仓库的提交历史就是记录实际发生过什么，它是针对于历史的一个文档，本身其实是有价值的，我们不应该随意修改。如果改变历史的话，就相当于使用“谎言”来掩盖实际发生过的事情，而这些痕迹是应该被保留的，可能这样并不是很好。
* 62a322d - (HEAD->master) Merge branch 'hotfix3' into master
|\
| * 6fa8f4a - (hotfix3) 3rd commit in hotfix3
* | 548d681 - 3rd commit in master
|/
* 6ba4a08 - 2nd commit
* 22afcc1 - 1st commit
② 使用 rebase 操作 Python 中的 Django 库使用
- 支持使用 rebase 的开发者，认为提交历史是项目过程中发生过的事情，需要项目的主干非常的干净，而使用 merge 操作会生成一个 merge 的 commit 对象，让提交历史多了一些非常多余的内容。
- 当后期使用 log 命令参看提交历史的话，会发现主干的提交历史非常的尴尬。比如，同样的修改内容重复提交了两次，这显然是分支合并导致的问题。
* 697167e - (HEAD -> master, hotfix) 3rd commit
* 6ba4a08 - 2nd commit (2 minutes ago)
* 22afcc1 - 1st commit (3 minutes ago)
③ 两者的使用原则
- 总的原则就是，只对尚未推送或分享给其他人的本地修改执行变基操作清理历史，从不对已经推送到仓库的提交记录执行变基操作，这样，才可能享受到两种方式带来的便利。
六、更新仓库提交历史
① 合并多个 commit 提交记录
- 日常开发中，为完成一个功能或者特性，我们会提交很多个 commit 记录。但是在最后，提交 PR 之前，一般情况下，是应该整理一下这些提交记录的，有些 commit 需要合并起来，或者需要将其删除掉等：
$ git rebase -i HEAD~5
$ git rebase -i 5af4zd35
reword c2aeb6e 3rd commit
squash 25a3122 4th commit
pick 5d36f1d 5th commit
fixup bd5d32f 6th commit
drop 581e96d 7th commit
$ git log
* ce813eb - (HEAD -> master) 5th commit
* aa2f043 - 3rd commit -> modified
* 6c5418f - 2nd commit
* c8f7dea - 1st commit
| 选项列表 |
对应含义解释 |
| p/pick |
使用这个 commit 记录 |
| r/reword |
使用这个 commit 记录；并且修改提交信息 |
| e/edit |
使用这个 commit 记录；rebase 时会暂停允许你修改这个 commit |
| s/squash |
使用这个 commit 记录；会将当前 commit 与上一个 commit 合并 |
| f/fixup |
与 squash 选项相同；但不会保存当前 commit 的提交信息 |
| x/exec |
执行其他 shell 命令 |
| d/drop |
移除这个 commit 记录 |
② 删除意外调试的测试代码
- 有时候我们提交之后，才发现提交的历史记录中存在这一些问题，而这个时候又不想新生成一个 commit 记录，且达到一个修改的目录，即修改之前的 commit 提交记录：
$ git --no-pager log --oneline -1
d5e96d9 (HEAD -> master) say file
$ echo "hello" > say.txt
$ git add -u
$ git commit --amend
$ git commit --amend --no-edit
$ git commit --amend -m "some_info"
$ git --no-pager log --oneline -1
9e1e0eb (HEAD -> master) say file
③ 取消多个 commit 中的部分提交
- 开发了一个功能，而在上线的时候，产品经理说这个功能的部分特性已经不需要了，即相关特性的提交记录和内容就可以忽略/删除掉，就可以如下操作：
$ git revert 3zj5sldl
④ 合并某些特定的 commit 提交
- 如果不希望合并整个分支，而是需要合并该分支的某些提交记录就可以：
$ git cherry-pick -x z562e23d
七、使用引用日志记录
- 使用下面命令回退内容、强制推送代码、删除本地分支，都是非常危险的操作，因为重置之后就没有办法在找到之前的修改内容：
$ git reset --hard <commit>
$ git push origin master -f
$ git branch -D <branch_name>
- 其实 Git 留了一个“后门”，就是使用 relflog 命令来找回之前的内容，只不过是相对来说麻烦一些。而原理也很简单，就是在使用 Git 命令操作仓库的时候，Git 会帮助我们把所有的操作记录下来：
$ git --no-pager log --oneline -1
4bc8703 (HEAD -> master) hhhh
$ git reset --hard HEAD~1
$ git reflog
6a89f1b (HEAD -> master) HEAD@{0}: reset: moving to HEAD~1
4bc8703 HEAD@{1}: commit (amend): hhhh
$ git cherry-pick 4bc8703
八、批量修改历史提交
- 上文中学习到的命令都是针对于一个或者多个 commit 提交信息进行修改的，如果我们需要全局修改历史提交，那么该怎么处理呢？当然，Git 中也是支持全局修改历史提交的，比如全局修改邮箱地址，或者将一个文件从全局历史中删除或修改：
-
-
-
- 这里可以使用 filter-brach 的方式进行修改，但是建议在使用之前，新建一个分支，在上面进行测试没有问题之后，再在主干上操作，防止出现问题：
$ git branch -b testing
$ git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_EMAIL" == "[email protected]" ]; then
GIT_AUTHOR_NAME="escape";
GIT_AUTHOR_EMAIL="[email protected]";
git commit-tree "$@"
else
git commit-tree "$@"
fi' HEAD
九、灵活使用钩子函数
- 在 Git 里面有两类，分别对应客户端和服务端钩子函数：客户端的钩子函数，是在执行提交和合并之类的操作时调用的；而服务端钩子函数，就是当服务端收到代码提交之后，可以出发代码检查和持续集成的步骤。作为开发者我们并不会搭建 Git 服务器，所以基本不会涉及。
- 如下所示，就是 Git 自带的钩子脚本，但是自带的都以 .sample 作为后缀，表示并没有启用，表示为一个示例，如果需要启用的话，将 .sample 作为后缀删除掉即可，而其钩子脚本的对应内容，都是使用 Shell 语法进行编写的：
➜ ll .git/hooks
total 112
-rwxr-xr-x applypatch-msg.sample
-rwxr-xr-x commit-msg.sample
-rwxr-xr-x fsmonitor-watchman.sample
-rwxr-xr-x post-update.sample
-rwxr-xr-x pre-applypatch.sample
-rwxr-xr-x pre-commit.sample
-rwxr-xr-x pre-merge-commit.sample
-rwxr-xr-x pre-push.sample
-rwxr-xr-x pre-rebase.sample
-rwxr-xr-x pre-receive.sample
-rwxr-xr-x prepare-commit-msg.sample
-rwxr-xr-x update.sample
- 其实，钩子脚本使用任何语言编写都是可以的，只要让程序返回对应的退出码就可以。正常的代码合入流程就是，本地修改之后，提一个 PR 请求并通过 Github 的 CI 检查，接下来进行代码评审，最后被合并入主干。
- 但是，好的一个习惯就是，在代码提交之前就应该保证代码不会出现语法错误等基础问题，比如通过 flake8 和 PEP8 标准等。这个时候就可以使用 pre-commit 这个 Github 的开源项目，其本质就是给项目添加钩子函数的一个脚本，可以保证在提交代码或者推送代码之前，先检查代码的质量。而 pre-commit-hooks 这个项目里面包含的就是，现在所支持的钩子脚本，即开箱即用的钩子脚本集合，而其钩子脚本的对应内容，都是使用 Python 语法进行编写的。
$ pip install pre-commit
$ pre-commit install -f --hook-type pre-push
$ cat .pre-commit-config.yaml
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v2.9.2
hooks:
- id: trailing-whitespace
- id: flake8
$ git push origin master
十、快速克隆大型项目
- 如果我们想为 Linux 或 Python 这样的大型项目贡献提交的时候，首先遇到的问题就是，如果快速的 clone 该项目到本地，因为改项目提交历史超多且仓库巨大，加了国内网络的问题，可能等项目完全拉下来的时候，会消耗大量的时间。
- 好在 Git 也帮我们想到这样的问题，我们可以使用 --depth 参数值拉取远程仓库上面最新一次的提交历史，并不包含项目历史记录，即 .git/objects/ 目录下的对象只是本地的，并不包含之前的多次修改产生的对象。
$ git clone http://xxx.xx.xxx/xxx --depth=1
- 但是，有时间我们可能会需要 clone 仓库中的某个 tag 版本对应下的内容，如果直接使用 clone 命令是无法做到的，需要执行如下操作，即可完美解决：
$ git init xxx-15-0-1
$ git remote add origin http://xxx.xx.xxx/xxx
$ git -c protocol.version=2 fetch origin 15.0.1 --depth=1
$ git checkout FETCH_HEAD
- 上面的效果已经基本可以满足我们日常的使用需求，但是不幸的是，如果你现在接受了一个机器学习的项目，里面包含了大量的 lfs 文件，现在 clone 又会变得非常慢，可以使用如下操作来避免，Git 工具主动拉去 lfs 文件，来达到目录：
$ GIT_LFS_SKIP_SMUDGE=1 git clone http://xxx.xx.xxx/xxx
十一、如何处理工作中断
- 比如，我们现在正在一个分支为项目添加一个小的功能，此时，产品经理找到你说是线上环境现在有一个 bug 需要让你来修复下。但是，此时我们添加的小功能并没有完成。
- 如果此时，直接切换到主干分支的话，会将之前分支没有来得及提交的内容全部都带到了主干分支上来，这是我们不想看到的情况。此时，需要保存上个分支的工作状态，在修改完成线上 bug 之后，再继续工作。
- 好在 Git 也帮我们想到了这样的问题，可以使用 stash 子命令帮助我们将当前工作区、暂存区当中的修改都保存到堆栈之中，等到需要处理的时候，再弹出堆栈中的内容，再次进行开发。
➜ git stash -h
usage: git stash list [<options>]
or: git stash show [<options>] [<stash>]
or: git stash drop [-q|--quiet] [<stash>]
or: git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
or: git stash branch <branchname> [<stash>]
or: git stash clear
or: git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [-m|--message <message>]
[--pathspec-from-file=<file> [--pathspec-file-nul]]
[--] [<pathspec>...]]
or: git stash save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [<message>]
$ git stash
$ git stash -u
$ git stash list
$ git stash apply <stash@{n}>
$ git stash drop <stash@{n}>
$ git stash pop
$ git stash clear
$ git checkout <stash@{n}> -- <file-path>
- 其实比较保险的做法就是，将当前的所有修改进行 push 并保存到远程仓库里面。这样的好处在于，可以远端备份我们的修改，不会害怕本地文件丢失等问题。等到需要继续开发的时候，拉下对应内容，再想办法进行补救，比如使用 --amend 或者 reset 命令：
$ git commit --amend
$ git commit --amend -m "some_info"
$ git reset a87f328
$ git reset HEAD~
$ git reset HEAD~2
$ git reset <tag>~2
$ git reset --mixed <commit/reference>
$ git reset --soft <commit/reference>
$ git reset --hard <commit/reference>
