❝

本文主要记录学习 Git 的过程。因为是学习笔记，可能有描述不全面或是不准确的地方，欢迎在评论区指正。

❞

本文的思维导图如下：

1. Git 安装和升级

安装应该不用多说了，主要讲一下升级。Linux 和 Mac 都有包管理器，升级是很方便的，关键是 windows 并没有这类东西，那么怎么升级呢？

这里首先要通过 git version 查看你当前的 Git 版本是多少，如果版本：

• <= 2.14.1 ：不要多想，老老实实卸载旧版本，安装新版本吧。。。
• 2.14.2 ~ 2.16.1 ：直接 git update 升级
• >= 2.16.1(2)：直接 git update-git-for-windows 升级

通过命令升级的时候可能半天没反应，最后提示你 using proxy as per lookup，如图所示：

那么不要犹豫了，你需要科学工具，否则速度绝对让你崩溃。如果没有的话，那也只能卸载再安装了，不过官网下载的速度也是相当之慢......

2. Git 乱码问题解决方案

以下操作基于 win10。

这个问题有点奇怪，直接使用 Git Bash 是不会出现乱码的，但是使用 windows terminal 后，在 git log 的时候中文会显示为八进制。你的问题可能和我不一样，也许是 git commit 或者 git status 的时候乱码。总之，我们可以统一设置：

git config --global gui.encoding utf-8
git config --global core.quotepath false
git config --global i18n.commitencoding utf-8
git config --global i18n.logoutputencoding utf-8
复制代码

最后执行：

export LESSCHARSET=utf-8
复制代码

然后新建一个环境变量，键名 LESSCHARSET，键值 utf-8。（这一步很关键，否则你新开窗口还是会乱码的）

注意：具体的设置可能因为系统（我是 win10）或默认编码不同而不同。我在解决这个问题的时候查看了很多博客，有的地方会说 git config --global i18n.logoutputencoding utf-8 这一步应该是设置为 gbk，不过我这样设置之后连 Git bash 也乱码了......（尽管 win10 的默认编码应该是 gbk 没错），所以在设置上还是得看你自己系统的情况，可能得多试几次。

❝

2020-05-27 更

❞

这个 windows terminal 果然不让人省心，今天发现 ls 指令也会有乱码的情况，而且目录不会高亮。最后在这个 issue 下找到了答案，两种解决方法：

① 编辑 git/etc/bash/bashrc 文件，末尾添加：

export LANG="zh_CN.UTF-8"
export LC_ALL="zh_CN.UTF-8"
复制代码

② 编辑 windows terminal 的 setting.json 文件：

"commandline": "D:\\Git\\bin\\bash.exe"
// 改为 
"commandline": "D:\\Git\\bin\\bash.exe -li"
复制代码

-li 参数可以让 git bash 以正确的配置启动。估计前面所有问题都和这个有关，因为我的 git 没有安装在默认路径，可能导致某些配置读取不了，出现各种奇葩的问题。

3. 初始配置

显示配置：

git config -l/--list
git config --global -l/--list
复制代码

进行配置：

git config --global username 'xxx'
git config --global useremail 'xxx'
复制代码

这里的参数可以是 local（对本仓库生效），global（对登录用户的所有仓库生效） 或 system（对所有用户的所有仓库生效），在优先级上依次递减。

4. 本地仓库操作

4.1 工作区相关

生成项目文件夹（本地仓库），同时生成记录重要信息的隐藏文件夹 .git：

git init project
复制代码

查看项目文件状态，红色表示文件还在工作区，绿色表示文件还在暂存区，不显示表示都到了历史区：

git status
复制代码

撤销本地文件的修改，使之回退到最近一次 git add 的状态：

git checkout -- <file>
复制代码

❝

上面这个命令和切换分支非常像（多了 --），容易混淆。为此，git 2.23 之后引入了专门的回退命令和切换分支命令，用来分离 git checkout 的职责。

❞

我们可以用下面命令进行工作区文件的回退：

git restore <file>
复制代码

有时候我们在工作区做一些修改的时候，可能临时接手了其它更紧急的任务，那么这时候就得把当前所做的更改做一个状态保存：

git stash
复制代码

在任务完成后，想要恢复之前保存的状态，则可以：

git stash apply
// 或者
git stash pop
复制代码

4.2 暂存区相关

提交文件到暂存区

git add <file>
git add .
git add -A 
复制代码

删除暂存区的文件

git rm --cached <file>
git rm --cached -r .
git rm <file>     // 删除工作区和暂存区的文件 
复制代码

修改工作区和暂存区的文件名

git mv <file1> <file2>
git commit -m'Change the file name'
复制代码

撤销对暂存区的文件提交

当我们修改文件并进行了 git add 之后，就不能再通过 git restore <file> 直接撤销本地文件的修改了。但可以先通过 git reset HEAD <file> 撤销对暂存区的文件提交（某个文件不提交了），再 git restore <file> 。

git reset HEAD <file>
复制代码

同样的，我们可以用新命令代替：

git restore --staged <file>
复制代码

这两个命令借助于 HEAD 进行恢复，因此运行在“至少提交了一次”的前提下（若没有提交则不存在 HEAD，使用命令是会报错的）。不过忘了也没关系，Git 会根据操作给我们相关提示的。

当我们不加 <file> 参数的时候，会撤销暂存区所有的文件提交（所有文件都不提交了），其实相当于恢复到了最近一次 commit 的状态：

git diff HEAD
复制代码

比对差异

在急着将工作区的文件提交到暂存区之前，可以先比对两个区的差异：

git diff
复制代码

如果目标是具体文件，也可以加上参数：

git diff --<file>
复制代码

同样，在急着将暂存区的文件提交到历史区之前，可能需要先将暂存区与最近一次 commit 进行比对，看看修改了什么东西（--cached 表示暂存区）：

git diff --cached
复制代码

4.3 历史区相关

提交文件到历史区

git commit -m'xxxxx'
git commit
复制代码

查看 commit 信息

git log
git log --oneline   // 查看简略的提交信息
git log --graph   // 查看图示提交信息
git log --n4        // 查看最近四次的提交信息
git log --all      // 查看所有分支上的提交信息
git reflog         // 查看包含回退在内的提交信息
复制代码

修改最近一次 commit 信息

git commit --amend
复制代码

修改以前的 commit 信息

如果要修改以前的 commit 信息，就需要变基（rebase）了。找到要修改的 commit 的前一次 commit id ：

git rebase -i <commit id>
复制代码

我们要修改的是 3291b88 这个 commit 的信息，将前面的 pick 指令改为 reword 指令，并保存：

来到另一个界面，在这里进行修改，之后保存退出即可：

合并多个连续 commit：

假设想要合并中间的多个连续 commit（2.txt 到 6.txt）：

基于这几个 commit 的前一次 commit id 进行变基：

git rebase -i ec7eeb3
复制代码

在这里会列出第一个 commit 往后的所有 commit，将想要合并的 commit 前面的指令改为 squash 指令，并保存：

编辑 commit 信息，这个信息会成为合并后的总 commit 信息，保存退出：

可以看到，commit 合并成功了：

合并多个非连续 commit：

针对上面合并之后的结果，如果我们想要合并第一个和最后一个 commit，那么可以基于第一个 commit 进行变基：

git rebase -i ec7eeb3
复制代码

在 rebase 的交互式界面中，只会显示第一个 commit 往后的 commit，但是我们这里需要用到第一个 commit，所以手动写入一个 pick ec7eeb3，并把第三个 commit 调整放到它后面，squash 有压入、塞入的意思，这里可以理解为把第三个 commit 塞入第一个中：

保存后会弹出一些提示，通过 git rebase --continue 再次回到交互式界面中。后面的步骤就和之前一样了：

再来打印看看，发现合并成功了：

版本回退

git reset --hard HEAD^ / HEAD~n
git reset --hard <commit id>
复制代码

比对版本差异

git diff <commit id1> <commit id2>
复制代码

4.4 分支相关

在介绍具体的指令之前，首先要搞清楚 HEAD，master 和 dev 三个指针的作用（不考虑版本回退的情况）：

• 在一开始，默认只有 master 分支（主分支），master 指针始终指向主分支的最近一次 commit，并在每次出现新的 commit 时向前推进；
• 如果新建分支，则会出现 dev 指针，它始终指向子分支的最近一次 commit，并在每次出现新的 commit 时向前推进；
• 不管当前处于哪个分支，HEAD 指针都指向该分支的最近一次 commit

假设最初只有一个主分支，第一次 commit 新建文本文件，第二次 commit 修改文件内容。下面结合例子和示意图介绍指令。

查看所有分支

git branch -av
复制代码

此时只有一个主分支，HEAD 和 master 指针都指向最近一次 commit：

PS：这里一定要注意，判断当前处于哪个分支看右边括号的内容即可，HEAD -> master 表示的并不是 HEAD 指针指向主分支，而是像示意图那样。

参数 -a 代表查看本地和远程所有分支，-v 代表查看分支的同时显示最后一次 commit 的相关信息。如果只想查看本地分支，可以：

git branch -v
复制代码

基于当前分支的最近一次 commit 创建并切换分支

git branch new_branch
git checkout new_branch
/* 或者 */
git checkout -b new_branch 
复制代码

此时有了子分支，由于它是基于主分支的最近一次 commit 创建的，所以三个指针指向同一个东西，即 HEAD -> new_branch,master

基于某次 commit 创建并切换分支

git branch new_branch <commit id>
git checkout new_branch 
/* 或者 */
git checkout -b new_branch <commit id>
复制代码

如果我们是基于第一次 commit 创建分支的，则指针的变动如下：

基于某个分支创建并切换分支

git checkout -b new_branch old_branch
复制代码

切换分支

git switch new_branch
复制代码

在 git 2.23 之后有了专门的切换分支命令。

合并分支

git merge new_branch
复制代码

删除分支

直接删除指定分支：

git branch -D new_branch
复制代码

删除前会先让用户确定分支是否已经合并：

git branch -d new_branch
复制代码

比对分支差异

假设当前提交情况如下：

要比较两个分支的差异，自然而然想到：

git diff master new_branch
复制代码

不过，前面我们知道，master 指针指向主分支最近一次 commit，dev 指向子分支最近一次 commit，正是这两个指针不同才得以将分支区别开来，而指针又是指向 commit，因此其实可以通过比对两个分支最近一次 commit 的差异，进而比对两个分支的差异：

可以看到，虽然两次 diff 的参数不同，但是结果是一样，这是因为「比对分支的差异，在本质上就是比对 commit 的差异」。

基于某次 commit 切换到“分离头指针”状态

git checkout <commit id>
复制代码

此时，我们会到达某次 commit 之后的状态，我们可以从此次 commit 的状态出发，进行一些试探性的修改。由于处在 'detached HEAD' state（“分离头指针”状态），所以修改不是基于任何具体分支的，一旦切换到某个具体分支，所有的修改都会消失。这适用于实验性的修改，可以避免影响其它任何分支。

其实，Git 给出的文字提示也很清楚。我们还可以注意括号里的内容，一开始是 master 分支，后来直接变成了某一次 的 commit id。同时可以看到，HEAD 不再像此前一样指向某个指针，而是「分离了」：

对应的示意图如下：

当然，我们可以执行下面指令：

git checkout -b new_branch
复制代码

此时就会真正创建一个分支，我们的修改得以保留。实际上就和之前的 git checkout -b new_branch <commit id> 效果一样。

4.5 Git 的三个重要对象（commit、tree、blob）

① 每一次提交会形成一个 commit 对象，根据 id 查看该 commit 对象的类型和内容：

git cat-file -t 'xxxxxx'   
git cat-file -p 'xxxxxx'
复制代码

② 该 commit 对象的 tree 对象是一棵文件结构树，它记录了提交时的文件结构快照（有哪些文件夹、哪些文件），根据 id 查看该 tree 对象的类型和内容：

git cat-file -t 'xxxxxx'    // tree
git cat-file -p 'xxxxxx'
复制代码

③tree 对象包含了 tree 对象和 blob 对象，分别指代文件夹和文件，我们可以进一步查看其类型和内容：

git cat-file -t 'xxxxxx'    // tree or blob
git cat-file -p 'xxxxxx'
复制代码

「注意最外层、最初始的 tree 是文件结构树，此后的 tree 是文件夹树」。比方拿下面这张图来看，第一棵树是文件结构树，内容是各个文件夹和文件，文件直接指代 blob 对象，而文件夹则指代另一棵树/ tree 对象。

5. 远程仓库操作

5.1 公私钥配置

查看本地公私钥配置情况：

ls -al ~/.ssh
复制代码

生成公私钥：

ssh-keygen -t rsa -b 4096 -C 'your_email@example.com'
复制代码

之后本地保存私钥，并在 GitHub 个人设置里配置公钥。

5.2 新建项目

第一步，先到 GitHub 创建一个远程仓库，拿到仓库对应的 ssh 或者 http 地址

第二步，创建本地仓库：

git init                          // 初始化当前文件夹为本地仓库
git remote add origin <Address>  // 本地仓库与远程仓库建立关联
git remote -v                   // 查看与本地仓库关联的远程仓库
复制代码

最后，本地提交一些修改，并推送到远程：

git add -A  
git commit -m'xxxx'    
git push origin master   
复制代码

PS：注意，如果之前建立远程仓库的时候勾选新建 README.md 文件，并且后来采用的不是 git clone 的方法，那么在这里是不能直接推送到远程的，因为本地与远程内容不一样（本地没有 README.md 文件），直接推送的话会报错。必须得先 git pull 把远程的东西拉下来同步，之后再 git push。

5.3 克隆项目

在前面的第二步，可以直接 git clone ，这样就不需要手动初始化本地仓库、建立远程连接以及同步等：

git clone <Address>
复制代码

不过，这只会克隆远程仓库的 master 分支。「以后」如果我们想要克隆远程的其它分支，可以：

git  branch  remote_branch_name  origin/remote_branch_name
复制代码

或者是直接切换到其它分支，Git 默认会帮我们建立一个追踪（track）远程仓库对应分支的分支：

git switch remote_branch_name
复制代码

如果一开始就只想要克隆某个分支，可以：

git clone -b remote_branch_name <Address>
复制代码

还有一种情况是，我们直接在本地建立了一个分支，忘记将它和对应的远程分支建立关联，这时候怎么办呢？可以这样：

git branch --set-upstream-to=origin/remote_branch  remote_branch 
复制代码

6. 多人开发

假设老大（项目负责人）新建远程仓库 X，并添加 AB 两人作为仓库的 contributor，那么 AB 就可以各自 clone 形成一个本地仓库，在做一些修改之后直接 push 到 X 仓库。

6.1 修改不同文件/同一文件不同区域

A 和 B 在同一个分支 remote_branch 上进行开发，A 修改 a 文件，B 修改 b 文件。在 A push 之后，B 是不能直接 push 的，因为本地仓库与远程仓库对应分支的内容还没进行同步。必须先执行下面的操作进行同步：

git pull origin/remote_branch
复制代码

这个指令其实做了两件事，第一件事是把远程已被 A 更新的 remote_branch 分支拉到本地：

git fetch origin/remote_branch
复制代码

第二件事是将这个目前最新的分支与本地 B 自己的分支进行合并：

git merge remote_branch origin/remote_branch
复制代码

最后再进行 push 就不会再报错了。

还有一种情况是修改同一文件的不同区域，因为修改的地方不一样，Git 还是可以帮我们进行 merge 的。

6.2 修改同一文件同一区域

因为上面的修改都是针对不同区域的修改，所以不存在冲突，Git 可以帮我们进行 merge。但是当修改同一文件的同一地方时，情况就不一样了：比如说 A 修改了 a 文件的某个地方，之后 push；B 同时也修改了 a 文件的这个地方，进行 push，之后报错，所以 B 选择先 fetch --> merge 再 push，但是在 merge 的时候还会报错（Auto merged failed）。

这是因为 A 和 B 都修改了同一个地方，Git 并不知道以谁的修改为准，因此 Git 无法帮我们做合并的工作。此时，就需要 B 手动去处理冲突，之后再 add --> commit --> push 才行。

6.3 修改同一文件的文件名

假设现在的场景是：A 修改 a 文件的文件名为 a1，之后 push；B 修改 a 文件的文件名为 a2，也想要 push，因为本地和远程不同步，根据之前解释的，到这里自然会报错，所以 B 决定先 pull 再 push，但实际上，在 pull 这一步的时候会再报一个错，提示无法进行 merge。

这和 6.2 其实是一样的情况，A 和 B 都想要修改同一个东西，Git 不知道应该以谁为准。假设 AB 经过协商，最终决定修改为 a2，那么对于 B 来说，他可以把本地的 a 和 a1 删除，再对 a2 进行 add --> commit --> push 的操作。（为什么会有 a1，是因为 pull 操作的 fetch 这一步是没问题的，远程拉下来之后本地会多出此前 A 更新的 a1 文件）

6.4 local，origin 和 upstream

在前面，我们是单人开发或者团队开发，可能只涉及到本地仓库和远程仓库，即 local 和 origin。假设 A 发现了某个第三方开源项目 ThirdParty/project 存在一些 bug，他想要进行修复，那么他就需要 fork 别人的仓库，形成自己的远程仓库 A/project，再克隆这个仓库形成本地仓库。那么，对于本地仓库来说，A/project 就是 origin，而 ThirdParty/project 就是 upstream。

local 和 origin 的同步

这个就是之前讲的情形，origin 是 A 自己的远程仓库，A 具有自由读写的权限，可以直接 pull 和 push。

local 和 upstream 的同步

如果本地仓库想要与原始仓库同步，第一步是先设置上游：

git remote add upstream <remoteAddress>
复制代码

查看当前配置的远程仓库（将包括 origin 和 upstream）：

git remote -v
复制代码

之后就可以与原始仓库进行同步了：

 git pull upstream master
复制代码

不过这里要注意，A 不是项目参与者，对原始仓库是没有写入权限的，因此无法直接进行 git push 操作。那么 A 怎么做呢？他可以先在本地把 bug 修复好，之后先 push 到 orgin 上去，再对原始仓库发起 pull request，等待项目负责人进行 merge。

origin 和 upstream 的同步

设置上游之后，本地可以与原始仓库保持同步，那么 origin 怎么与原始仓库同步呢？我们需要反向 pull request。这里可以以「掘金翻译计划」这个项目为例。在我们自己的仓库点击 pull request 来到这个界面：

注意这里的 head 和 base，一开始是 origin 指向 upstream，表示我这边更新了东西，想要原始仓库去合并；不过现在的情况是反过来的，我们可以看作是原始仓库更新了东西，想要我们去合并。所以将 head 和 base 改为从 upstream 指向 origin：

可以看到，因为有很长一段时间没有同步更新了，所以多出了整整 800 多个 commit。到了这个界面，就可以正式创建 pr，然后我们自己来 merge 了。这样，origin 和 upstream 就保持了同步。

参考：

玩转 Git 三剑客

廖雪峰 Git 教程

最后是个人的公众号，最近在学习操作系统和编译原理，关于这方面的笔记会比较多。以后的话则基本和前端相关。我还在持续学习的路上，文章会尽量以原创和翻译为主，如果感兴趣的话可以关注一下~

本文使用 mdnice 排版