[ Git ] 重学Git三剑客

Posted 2023-01-12 削尖的螺丝刀

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了[ Git ] 重学Git三剑客相关的知识，希望对你有一定的参考价值。

[ 概览 ]

《 Git三剑客》
————————————————————————————————————
Git：是Linux之父开发的 分布式 版本控制系统。

GitHub： 是对Git的一个封装，提供个人/组织等代码管理、搜索等服务。

GitLab： 是对Git的一个封装，提供定制化的的代码管理、持续继承持续开发等全流程服务。

[ 集中式管理系统 - 如SVN等 ]

[ 分布式管理系统 - Git ]

由上可知分布式的版本控制，不需要时刻连接服务端，不但解耦，操作也更方便，高效

PS : 本文出自对极客时间 —— 《玩转Git三剑客》 的学习总结，由于之前公司用的都是SVN，对GIT的系统了解甚少，索性在周末看完了这个专栏，如果你也对GIT感兴趣，或者正在追这个专栏，欢迎一起探讨，交流学习！

[ 初探 ]

01 | Git的安装

git文档官方网址：

https://git-scm.com/book/zh/v2/
下载对应系统的.exe安装包，解压安装【一路下一步即可】

验证是否安装成功方法：打开电脑cmd指令窗口，输入
```
git --version
```
输出如上图即安装成功

02 | 使用Git之前需要做的最小配置（姓名和邮箱必填）

配置 user 信息

配置 user.name 和 user.email

注：目的，方便项目管理人员通过提交记录指正问题或者与提交者沟通相关问题；
```
$ git config --global user.name 'your_name'
$ git config --global user.email 'your_email@domain.com'
```
通过下面命令能看到刚才配置的信息
```
git config --global --list
```

config 的三个作用域( 优先级：**local > global > system **)

缺省等同于 local

$ git config --local    // local 只针对某个仓库有效
$ git config --global   // global 对当前用户所有仓库有效
$ git config --system   // system对系统所有登录的用户有效【不常用】

显示 config 的配置，加 --list【注：--list后需要加空格来匹配查询范围】

$ git config --list --local 
$ git config --list --global    
$ git config --list --system

思考：配置用户信息时，local 和 global 有哪些区别？

03 | 创建第一个仓库并配置local用户信息

建 Git 仓库

两种场景：

（1）把已有的项目代码纳入 Git 管理**（在当前文件夹内执行bash，把当前文件夹纳入git）**
```
$ cd 项目代码所在文件夹
$ git init
```
（2）新建的项目直接用 Git 管理**（执行bash指定一个文件夹，把指定的文件夹纳入git）**
```
$ cd 某个文件夹
$ git init your_project     #会在当前路径下创建和项目名称同名的文件夹
$ cd your_project
```
在新建仓库中，若同时配置global 和 local 的用户信息时，Git 如何处理？

commit 记录时，用户信息权重优先级比较：

当前仓库 local 信息 > 其他仓库 local 信息 > 全局 global 信息

04 | 通过几次 commit 来认识工作区和暂存区

[ git的存储提交结构 ]

工作目录： 就是你正在操作的代码是所在的本地文件夹
暂存区： 你可以理解为一个草稿箱，但是此时已经由Git管理了，已经写改完的内容暂时放到这个草稿箱，后续可以对其做任意修改。
版本历史：你把草稿箱的内容提交到中央仓库后，就会生成版本历史了，相当于你的本地草稿代码已经进入中央管理的正式代码了

往仓库里面添加文件

（1）加入 index.html 和 git-logo

（2）加入 style.css

（3）加入 scrpit.js

（4）修改 index.html 和style.css

工作目录 —> git add files —> 暂存区 (可通过git status查看文件状态)—> git commit -m’输入提交信息’ —> 版本历史

ps：未被管理的文档，在 git status 后显示如下

在git add images index.html 后再运行 git status 状态就变成绿色了（即已经放入暂存库）
指令：git add -u == git add 具体的文件名（也就是说git add -u 会自动添加所有做了更改的文件到暂存区，u代表update）

最后通过 git log 可以看到最近的提交信息（最上面的最近）

05 | 给文件重命名的简便方法

步骤

重命名文件 —> git add 文件名【添加新文件】—> git rm 文件名【移除旧文件】

git reset --hard 【清除暂存】将暂存区和工作区目录上的所有的更改清除掉 （慎用）

上面的步骤要两条命令，这里有一个简化步骤，一条命令即可把暂存区的文件重命名，然后提交即可：
```
git mv readme readme.md
```
注：在window和os系统中对于大小写的敏感度会影响修改结果，需要特别留心

06 | 通过git log 查看版本演变历史

git log 【查看当前分支的版本历史】的常用用法

git log --oneline       // 简单的查看版本列表历史有哪些修改
git log -n4 --oneline   // 查看最近4次的提交历史
git log -n2 --oneline   // 查看最近2次的提交历史
git log --all           // 查看所有分支的提交历史
git log --all --graph   // 图形化提交分支历史

// 一些组合
git log --oneline --all     // 所有分支提交历史记录列表
git log --oneline --all -n4     // 所有分支最近四次的提交历史记录
git log --oneline --all -n4 --graph     // 所有分支最近四次的提交历史记录图形化
git log --oneline temp      // 指定分支提交历史记录列表

// 特例
git log --oneline --all temp    // all之后再指定分支是不起作用的，all的优先级更高

// 其他
git branch        // 查看本地分支信息
git branch -v     // 查看相对详细的本地分支信息
git branch -a     // 查看所有分支信息
git branch -av     // 查看包括远程仓库在内的分支信息
git help --web log // 跳转到git log 的帮助文档网页

命令行与图形界面各自利弊

简单总结：因人而异；
什么时候用’–‘什么时候用’-'的问题

网友给出的理解：

（1）与Linux大致规则相同，- 后面跟一个字符，如-a,-b； – 后面跟的是字符串，如–version，–all

（2）参考help文档查看规律，详细参数需要使用–，简化参数使用-
git help --web log 报错 fatal:’/usr/local/git/share/doc/git-doc’:not a documentation directory.

问题节点：当前路径下缺少git-doc文件夹，方案百度即可；

造成问题的原因：电脑跟新git版本冲突，导致文件缺失；
git help -4 <==> git help -n4

原文档中提示： ‘-’ 通 ‘-n’
git log 模式退出需要按q退出，有时则不需要？

当控制台窗口足够大，能够显示所有的日志信息时，就不会进入vi的浏览模式

07 | gitk: 通过图形界面工具来查看版本历史

git 管理的项目目录下cmd命令窗口输入gitk即可弹出对应可视化窗口；
gitk 可能存在的问题：

（1）中文乱码；【百度即可找到解决方案】

（2）直接输入gitk报错，可能原因：git 版本问题；安装时未安装gitk，需要手动安装；

输入gitk即可弹出提交详情的图形界面，或者在gitBashGUI中寻找此选项，结果如下：

还有很多功能可以在这个图形化界面自探索，比如最上面的view —— > createView，可根据选项创建一个新的浏览结果，比如All refs打钩，那所有提交的详细信息（包括分支）都会出来：

图形化工具推荐：

gitkarken、sourcetree、tower、tortoise

概念理解：

Author    // 作者
Committer    // 提交人
// 意义：尊重原作者

08 | 探秘 .git 目录

ls -al // linux命令，显示当前目录下的所有文件及文件夹包括隐藏的.和..等的详细信息

其中常用的有HEAD【作用：告知当前工作分支】
```
cat fileName    // linux 指令平时用的最多的主要是在终端查看某个文件
ref:refs/heads/master   // 意指当前指向分支为 master 分支
```
注：当执行 git checkout temp 切换到新创建的temp分支后，其指向将更新为ref:refs/heads/temp
config 内部内容【和本地仓库相关的配置信息】

refs 内容

heads ---> 对应项目中不同的分支（不同分支之间的操作互不影响，最后合并到主线即可）

tags ---> 意味着项目中可以有多个标签【又称里程碑,比如开发到了某个关键的版本，那这个版本就是个里程碑，所以要打个tag】

git cat-file -t 提交关键编号  // 查看编号类型
// commit 生成的字符串即可以理解为通过算法生成的哈希值

注：tag 本身拥有一个哈希值—>存放着一个对象，对象的值为另一个哈希值—>这个对象的类型是个commit

objcets

git cat-file -t // 看类型
git cat-file -p // 看内容
tree    // 树
blob    // 文件对象
commit  // 对象
// tree、blob、commit git的三个核心对象

注：树的策略为 e9 + 哈希值

09 | commit、tree 和 blob 三大核心对象之间的关系

commit 【提交】—> 【含有】tree（特定时间点的所有文件快照）—>blob【具体的文件】

白话：一次提交的信息里面含有tree（这个tree就是提交当时所有文件的一个快照，你可以理解tree就是文件夹，子tree就是子文件夹），然后tree中含有blob（blob就是具体的文件，不管多少次提交，如果内容相同的文件只会被视为一个blob，节省了内存空间）

png 为特殊格式的二进制文件，故而命令行cat 解析成乱码;
git 本身有增量存储机制，应对commit无数次后，objects目录中文件的不断累积叠加；

其次，Git 对于内容相同的文件只会存一个blob，不同的commit的区别是commit、tree和有差异的blob，多数未变更的文件对应的blob都是相同的，如此设计从而对版本管理系统来说节省了很多的存储空间；
git底层的运行流程了：

（1）当我们添加或者修改了文件并且add到Stage Area之后，首先会根据文件内容创建不同的blob

（2）当进行提交之后马上创建一个tree组件把需要的blob组件添加进去

（3）之后再封装到一个commit组件中完成本次提交。

在将来进行reset的时候可以直接使用 git reset --hard xxxxx 可以恢复到某个特定的版本，在reset之后，git会根据这个commit组件的id快速的找到tree组件，然后根据tree找到blob组件，之后对仓库进行还原，整个过程都是以hash和二进制进行操作，所以git执行效率非常之高

（4）对于tree的理解：git 中的文件夹是通过 tree 来组织的，so，可以把 tree 对应于文件夹对象;

10 | 练习：数一数 tree 的个数

题目：新建的Git仓库，有且仅有1个commit，仅仅包含/doc/readme，请问内含有多少个tree，多少个blob?

commit 【创建后】—> 生成tree 【与文件夹同级，可理解为文件夹目录对象】—> blob 【若对象下只含有一个文件，则指向这个文件对象，即blob对象】
思考：若不让readme文件中写入信息，加入暂存区后Git是会创建一个空的blob对象，还是不创建呢？

11 | 分离头指针情况下的注意事项

在 git checkout [ 某个commitId ] 的时候，就会弹出detacheHead-分离头指针，本质上是说当前的点没有打分支，我们正工作在一个没有分支的状态下（就是在另一个临时的空间做代码改动） —— 在这个状态做的代码改动，如果突然要你去再checkout到master主线，或者某个分支做改动，那这个分离头指针下的临时改动就可能被清除掉，所以我们要做改动，请在挂钩的分支上做改动。

但是分离头指针有一个场景，就是你想先对当前代码做个变更试试，如果觉得没问题可以直接再对分离头指针打一个分支进去 git branch fix_css [ 分离指针的id ]，反之可直接无视（不提交这块，不去管了），checkout到新的分支就行了。

情况英文描述：

You are in 'detached HEAD' state.   // 你正处在一个分离头指针状态

产生原因指令

git checkout 某个commit的hash值     // 未与分支挂钩

好处与风险

（1）好处：可以基于某个commit做任何修改，不满意时，直接切换回之前分支即可；

（2）风险：分离头指针状态下所做修改如果不和任何分支挂钩，日后切换分支时会被git清理掉，所做更改一并删除；

注：分离头状态更改在切换分支后虽然扔存在一段时间，但是取回来相对麻烦，并且Git定时会清理不要的东西
思考：什么情况下可以使用分离头指针？

场景1：若想基于某个commit做变更，试试新的方案是否可行，就可以采用分离头指针的方式。测试后发现不成熟，直接reset会其他分支即可。省却了建、删分支的繁复操作；

提示： commit -am 的话可以直接提交到中央从库，省去了add 到暂存区的步骤（实际这个命令已经帮你完成了这个步骤），如果你觉得不需要每次先保存到暂存区而直接提交的话，可以这么用。

深入

[ 进一步理解HEAD和Branch ]

注意这个黄点就是HEAD，它永远是你当前正在操作的一个分支，也叫做最新一次Commit的位置（不管是主线分支还是支线分支）

[ 比对 ]

git diff HEAD^ 或者 ~number 可以和父级提交的内容做比对

"^"这个操作符代表父commit。
当一个commit有多个父commit时，可以通过在符号“^”后面跟上一个数字来表示第几个父commit。
比如，“A^” 等于 “A^1”(表示A这个commit的第1个父commit)。

连续的“^”符号依次沿着父commit进行定位，直到某个祖先commit。

~ 相当于连续n个符合“^”。
所以，HEAD^^ 等同于 HEAD~2 是对的。
还有，这些都可以自己做实验测试一下的。

[ 分支删除 ]

git branch -d 分支id
如果有未完成的merge，确定要删，那句把d改成大写 git branch -D 分支id

[ 对Commit的message做修改（仅用在自己维护的分支上，如果已经合并主线不要这样改） ]

针对最近一次的commit： git commit --amend
针对历史commit：
- 1.先git log找出要改的commit
- 然后选择这条要改的commit的下面一条作为baseCommit，命令就是git rebase -i 父commitID
  - （这时候会弹出下面的内容，我们接下来要改message但是要保存内容，所以把直接选用pick改为reword选用但改message）
  - 保存后会自动弹出一个让你改message的框，你把message改完保存即可（比如我这里改成了NEW rename Readme）

[ 将多个Commit合并为一个总的Commit （仅用在自己维护的分支上，如果已经合并主线不要这样改） ]

为什么这样玩呢？因为你可能觉得我提交的多次Commit是一个整体的逻辑，可以合并到一个Commit看的更简洁些，那就能这样弄。ps: 这里为了演示，用了master

同样，还是要选一个父commitID作为合并的对象的起点范围 git rebase -i 父commitID

弹出的内容保存一个pick作为另外commit要和入的对象，其他的改为squash代表待合并
保存后弹出的信息，加一句自己的新message即可

保留一个pick作为合并的对象，那么就是说下面两个合并到pick的那个commit里去

三次变更的信息都留下了，然后再添加一句新的变更信息

可以看到变成两个commit了

类似上面的操作，如果想要合并多个非连续的commit，（比如base的那个CommitID不显示，只需要把ID拿出来放到rebase弹出框里然后做相应修改即可），具体细节在这一集 —— https://time.geekbang.org/course/detail/100021601-72798

但多个非连续的commit合并，那树状图就会断开，也就是最新提交的父节点是刚才合并的一个新的commit，在此之后的commit就断开了，如下（可以看到Add readme.md和temp是断开的）：

[ 怎么比较暂存区和Head所含文件的差异 ]

git diff --cached 或者 git diff —staged

[ 怎么比较工作区（正在操作的区域，非add或commit的区域哦）和暂存区所含文件的差异 ]

git diff

如果只对特定文件的区别感兴趣，那就在后面双横杠+文件名即可，要看几个就加几个文件名，如下

假定：HEAD、缓存区、工作区中的readme.md文件内容均不相同。
git diff HEAD – readme.md # 工作区 <== => HEAD
git diff – readme.md # 工作区 <= ==> 缓存（暂存）区
git diff --cached – readme.md # 缓存（暂存）区 <= ==> HEAD

[ 怎么把暂存区恢复成和HEAD一样？怎么把工作区恢复成和暂存区一样？]

暂存区所有的信息都不想保留了，只想恢复的和Head一样（也就是暂存区add的内容全部撤回到工作区，变成待add内容），如下命令即可（不过这样的需求应该很少，因为如果觉得对暂存区不满意，那工作区修改继续add就行，会覆盖的）

git reset HEAD

改了半天，发现工作区的内容不想要了，还是目前暂存区的好，那把工作区全部恢复成暂存区的内容，命令如下

git checkout – 要恢复的文件名 （注意这–左右有两个空格）

[怎样只把暂存区部分恢复的和HEAD一样？]

git reset HEAD – 要回复的文件名 （多个文件名用空格隔开即可）

[ 🦄 怎样将最近提交的数据，撤回至之前提交的某个版本（回退版本）？ ]

git reset – hard 具体的commitID ，这样工作区和暂存区都会回退到这个版本，如果想保留工作区就不要用 – hard，如果工作区和暂存区都想保留，那就改为 – soft

至此做一个小结 —— 以上的操作都是不能恢复的，哪怕是你撤回了又想改回去，所以这些命令请在自己确认需求后，再使用。

[ 如何比较两个分支，或者两个commit之间的区别 ]

git diff commit_id commit_id – 想要比对的文件名
git diff 分支名分支名 – 想要比对的文件名

[ 如何删除文件并保存到暂存区准备提交？ ]

git rm readme 直接将删除文件并存到暂存区

[ 正在工作区开发的时候，线上bug要改的新任务该来加塞怎么办？ ]

git stash 把当前工作区的内容放入暂存区
git stash pop 把暂存区的内容恢复到工作区，且删除
git stash apply把暂存区的内容恢复到工作区，且保留

这个其实用的少，几乎都是新拉分支，老分支提交上就行，两个分支互不影响。

[ 🦄 如何指定不需要Git管理的文件？ ]

把不需要管理的文件写在 .gitignore 文件中（注意必须是.gitignore文件名，否则不生效，这个gitHub或者IDEA插件，对于JAVA代码会自动生成），格式为

filename —— 这个文件夹和文件夹下的所有文件全部无视
filename/ —— 这个文件夹还是管理，但其下面的所有内容都无视
*.后置名 —— 无视某种类型的文件

如果已经误提交了已经提交的文件，想删除怎么办？

把想忽略的文件添加到 .gitignore ；然后通过 git rm – cached name_of_file（这个命令会同步删除工作区中的文件）的方式删除掉git仓库里面无需跟踪的文件。

13.将Git仓库备份到本地

[ 哑协议与智能协议的区别 ]

直观区别： 哑协议传输进度不可⻅；智能协议传输可⻅。

传输速度： 智能协议⽐哑协议传输速度快。

日常用最多的就是https和ssh（ssh协议需要配置公/私钥）

Push - 推送： 本地备份到远端

Fetch - 拉取： 远端备份到本地

交互方式

1）找个目录执行 clone （这时候是没有关联的，无法push和fetch）
2）或者，用init建个git仓库，然后从备份数据库添加remote（建立关联）再push到新建仓库；或者
3）或者，用init建个git仓库，然后在新仓库添加remote（建立关联，如果上面弄好了关联这步可不做），再把备份数据库fetch/pull到新仓库（pull是把远端的分支和本地分支建立拉下来后，同时和代码做了一个merge操作。而fetch是只完成了前面异步，后面的merge要另外做）。

交互命令

git remote -v 查看远程版本库信息
git remote add githup 添加githup远程版本库
git fetch githup 拉取远程版本库
git merge -h 查看合并帮助信息
git merge --allow-unrelated-histories githup/master 合并githup上的master分支（两分支不是父子关系，所以合并需要添加 --allow-unrelated-histories）
git push githup 推送同步到githup仓库

—— 注意，任何从远端（比如Github），拷贝代码到本地用clone命令就可以了，如果要和远端发生关系，也就是本地代码可以提交上去，远端也可以拉取下来，那必须用remote命令建立起这个桥梁（只要想和远端发生关系都要用remote命令，至于远端地址，比如gitHub，那仓库是有ssh地址可以拷贝的，帮助文档也有说明）

14.GitHub仓库

这里主要说SSH（配好后不需要每次都输入密码，可直接push/fetch，工作中的创建设置方式也是这样）网上都有很多步骤，github官方也有说明文档，就不细说了，大概步骤如下：

配置SSH公/私钥(如果已有则不需要配置，如何查看github说明文档有)
把配置好SSH公/私钥生成的Key拷贝到GitHub的SSH配置中保存
生成自己的Repository仓库，拷贝仓库的SSH地址，准备用来给本地添加
本地通过git remote add name remoteRepositoryName 命令来添加远程仓库
接下来就可以完成pull、push/fetch + merge等交互命令啦

15.多人协同开发 💫 💫 💫 🐑 🐐 🏇

在团队中使用Git的法则
1：push前一定先pull
2：合并代码必须两人结对
3：合并冲突，非自己的变动保持原样，和自己冲突的代码找相应的代码提交人确认如何解决冲突
4：合并完成后，保证本地能编译能运行再push
5：【合并到主干的代码必须通过测试，必须通过代码review 】
6：【不同的功能从主干上拉新分支进行开发工作，开发完后确认无误再合并到主干】
7：分支的命名需要加上，拉取人＋拉取说明
8：上完线的分支要及时清理

关于什么情况下用Fetch + merge/rebase，什么情况下用pull（自动merge）的问题

如果你不想拉下来直接就和工作区的合并，想先看看有什么不同再说，或者公司要求线性历史，那就fetch下来做rebase

如果你想拉下来就直接自动merge好了，那就用pull

（如果有冲突，二者在merge的时候都会报异常让你手动修改再merge的）

[ 补充说明merge和rebase的区别 ]

merge： 如下，两个蓝节点从最底层的蓝节点开始产生分叉，意思是两个人从这个节点开始做了修改，那merge后，两个节点的显示就会在（HEAD）黄点位置合并。

rebase：如下，rebase过后的节点永远不会有分叉，假设当前在A分支，要基于B分支做rebase，那么，先找到A和B最近的公共祖先C1，从C1到A之间的所有commit，都基于B重新生成新的commit。也就是会从B开始合并生成一个新的线性节点。

[ 不同人修改不同文件如何处理？ ]

不管怎样都是现Fetch远端分支 —— 注意Fetch下来后是存在本地的中央仓库，工作目录还未同步，比如下面（在Fetch完后，使用git branch -av 查看分支信息）

你可以看到，当前操作的分支 ——

ahead 1 表示本地工作目录有一个更新是中央仓库没有的
behind 1 表示中央仓库拉下来的更新数据有一个是工作目录没有的
拉取完就是合并了（因为拉到的是本地中央仓库，还没和工作目录合并） —— 此时如果
- 公司没有对提交历史进行线性展示的要求，就使用 git merge 远端仓库分支名即可
- 反之如果有线性展示要求，则要用git rebase 远端仓库分支名（这个具体的rebase参数和过程还要问老员工）
合并完后，就是把最新的代码push到远端 了

至此，对于相互不冲突的提交信息，进行一个合并/同步的工作就完成了！