Git学习笔记
1，引言
Git官网链接: https://git-scm.com/
首先我们把Git官网首页上的两句话翻译成中文感受一下。
-
Git 是一个免费的、开源的
分布式版本控制系统，可以快速高效地处理从小型到大型的各种项目。 -
Git 易于学习，占地面积小，性能极快。 它具有廉价的本地库，方便的暂存区域和多个工作流分支等特性。其性能优于 Subversion、CVS、Perforce 和 ClearCase 等版本控制工具。
当从个人开发最终过渡到团队合作的时候，就需要经常使用Git。
2，Git 工作机制
工作区：存放代码的磁盘位置；
暂存区：在工作区写完代码后，需要让Git追踪到有这样一个代码文件，就需要把工作区的代码添加到暂存区临时存储；
本地库：提交到本地库的代码就会生成历史版本；
注意工作区和暂存区写过的代码，如果感觉不合适都是可以删除掉的，并不涉及历史版本记录问题。
但暂存区中的代码一旦提交到本地库，就会生成历史版本，代码就无法删除了。
举一个生活中的例子理解以上三个分区：
小蜗是某公司程序员，某天喝多了，在自己的程序里写进了一些骂老板
的代码注释。在工作区写完此代码老板肯定看不到，但小蜗为了追求刺
激，把代码添加到了暂存区；这种情况酒醒之后代码也可以进行删除，
老板也看不到，因此还可以补救。但如果一时冲动，把添加到暂存区的
代码 提交到了本地库，那么就会生成一个历史版本。这个时候，骂老板
的代码就无法删除了，小蜗酒醒之后，只能修改自己提交的版本进行补救，
但老板仍然可以通过git查看之前的版本，依然存在被发现的风险。最终
小蜗删库路路！！！
3，Git和代码托管中心
代码托管中心是基于网络服务器的远程代码仓库，一般我们简单称为远程库。
我们知道，提交到本地库的代码可以形成历史版本。这时我们还可以通过push
命令把代码从本地库推送到远程库。
代码托管中心分类：
4，Git常用命令
4.1，设置用户签名
签名的作用是区分不同操作者身份。用户的签名信息在每一个版本的提交信息中能够看到，以此确认本次提交是谁做的。
Git 首次安装必须设置一下用户签名，否则无法提交代码。
- git config --global user.name 用户名 ：设置用户签名
- git config --global user.email 邮箱 ：设置用户签名
※注意：这里设置用户签名和将来登录 GitHub（或其他代码托管中心）的账号没有任何关系。
验证是否操作成功：
找到C盘的用户目录进入当前用户目录，可以找到一个.gitconfig文件打开可以看到我们设置过的用户签名信息，即成功设置了用户签名。
4.2，初始化本地库
需要使用Git管理这个目录的时候，就首先需要先进行初始化来使Git获取此目录的管理权。如下图我们在e盘的GitSpace/git-demo目录下进行初始化，然后在此目录下（右击空白处选择Git bash here，就进入了此目录）。
git-init命令
初始化成功之后就会生成一个.git目录，图形化界面如图展示。
也可以使用Linux命令进行查看
其中ll命令是查看目录，但由于.git文件是隐藏的，因此无法显示。可以通过ll-a命令显示全部文件。
4.3，查看本地库状态
git status
首次查看本地库状态（工作区没有任何文件时），会输出这样三行日志。
①On branch master：提示当前本地库在master分支（默认分支名字，表示当前分支）里面；
②No commits yet：表示目前还没有提交过任何东西，目前是一个空的git库；
③nothing to commit (create/copy files and use “git add” to track)：目前没有什么东西需要提交。
新增文件后再次查看本地库状态
vim.hello.txt可以创建并进入hello.txt。
常用的vim命令：
- i进入编辑状态，写入内容;
- esc进入命令模式；
- yy：复制；
- p：粘贴；
- :wq保存（退出insert编辑状态后才可以使用）；
- X向前删除一个字符；
- x向后删除一个字符；
- dd删除一行
①文件中插入一些内容
②cat查看文件内容
③查看尾部内容
$ tail -n 2 hello.txt查看尾部第二行（回顾Linux命令）
此时再次查看本地库状态：
Untracked files: --------未被追踪的文件。说明此时hello.txt虽然有了，但只存在于工作区。
nothing added to commit but untracked files present (use “git add” to track)-----现在没有提交过任何东西，但有一个未被追踪的文件了，要使用git add进行追踪（添加暂存区）。
4.3，添加暂存区
git add加文件名
日志信息：warning: in the working copy of ‘hello.txt’, LF will be replaced by CRLF the next time Git touches it。—Git默认转换了行末换行符。
（警告不用管，问题不大）
Windows系统里的换行符是CRLF；Linux系统里面换行符是LF。
提交到暂存区之后继续查看本地库状态。
hello.txt由红色变为绿色，说明当前的Git已经追踪到了这个文件。（文件存到了暂存区），此时依然可以删除。 使用git rm --cached 加文件名。
删除操作如下图，删除成功后查看本地库状态，发现hello.txt又变为红色：
注意：删除暂存区中的文件，工作区中的文件依然存在。
4.4，提交本地库
对添加到暂存区的文件提交至本地库。形成自己的历史版本。
git commit -m “日志信息” 文件名
日志信息：[master (root-commit) f785f7a] first-commit
1 file changed, 17 insertions(+)
create mode 100644 hello.txt
master(主干分支)：第一次提交版本，一个文件被改变。17行内容被插入；
f785f7a即为版本号。
再次查看本地库状态：
On branch master：当前是master分支
nothing to commit, working tree clean：已经提交过了，并且提交后文件没有新增也没有修改工作树很干净。不需要再次提交。
4.5，查看版本日志信息
git reflog：查看引用日志信息（精简信息）。
git log：查看详细日志信息（详细信息）。
完整的版本号为：f785f7a29ddd59c5a9c5b5babbab3592dc37b554
使用reflog查看到的版本号为前七位精简版的版本号f785f7a
4.6，修改文件
①先查看文件信息，如下图
②进入编辑状态，修改文件，比如第一行后增加空格和7个3，如下图
③查看本地库状态，如下图
这时我们发现modified: hello.txt-红色信息说明文件被修改了，并且还没有被添加到暂存区。（即Git还没有追踪到本次修改）。
所以我们对修改后的文件，使用git add添加到暂存区。如下图
添加完成后，再次查看本地库状态。，如下图。
这时我们发现出现绿色提示信息。说明文件已经被添加到暂存区了。
接下里提交到本地库
注意日志信息最后一行提示： 1 file changed, 1 insertion(+), 1 deletion(-)
表示：一个文件被修改；其中一行新增，一行删除。
-
为什么我们对文件一行进行修改，会提示一行新增，一行删除？
因为Git中是通过行来维护文件，“修改了一行” 只能通过 “一行新增，一行删除” 来表达。
再次查看本地库状态，发现提交成功，如下图
查看版本日志信息，发现有两个版本：first-commit和second commit。
而且当前的指针指向的是第二个版本：
（ (HEAD -> master) HEAD@{0}: commit: second commit）。
此时查看文件信息，即为第二个提交版本的信息，如下图。
同理，如果再次对文件进行修改，如在第二行加上一个hhh。然后进行一系列操作：添加暂存区、提交本地库。
再次查看日志信息，如下图：
注意：尽管此时已经有了三个版本，但Git的工作区依然只有一个文件，如下图。因为Git控制版本是通过指针而非副本。
4.7，关于历史版本
①查看历史版本
比如初到公司，如果需要查看当前项目经历了几个版本的迭代。可以使用git reflog命令（查看精简版日志）或者git log命令（查看详细版日志），如下图：
②版本穿梭
如果有一天老板感觉最新版本的代码还不如之前版本合适，就要求员工穿梭回原来的版本。
比如们想从第三版穿越回第一版，就可以先查看版本信息，复制第一版的版本号 f785f7a 。
通过命令 git reset --hard 后面加上版本号，如git reset --hard f785f7a
版本穿梭完成后继续查看日志，如下图：
穿梭之后我们查看文件信息，cat hello.txt。发现文件内容已经穿梭到了第一次提交的版本。
版本穿梭，底层使用head指针。
5，Git分支
5.1，什么是分支？
在版本控制过程中，同时推进多个任务，为每个
任务，我们就可以创建每个任务的单独分支。
使用分支意味着程序员可以把自己的工作从开发主线上分离开来， 开发自己分支的时候，不会影响主线分支的运行。 对于初学者而言，分支可以简单理解为副本，一个分支可以理解为一个单独的副本。（分支底层实际上是指针的引用）
5.2，分支的好处
- 同时并行推进多个功能开发，提高开发效率。
- 各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。
5.3，分支操作
① 查看分支：git branch -v
上述信息显示：当前的demo只有一个master分支，并且有三个历史版本。
② 创建分支： git branch 分支名
比如，程序出现问题了，
我们通过git branch hot-fix创建一个紧急修复（hot-fix）分支，
然后通过git branch -v查看分支。创建成功，如下图
③ 修改分支
接下来操作实现从master分支切换到hot-fix分支上，去修改hello.txt
切换分支： git checkout 分支名，如下图：
vim hello.txt 编辑 hello.txt 删除第二行的hhh。如下图：
删除之后，查看本地地库状态。如下图
红字表示有修改的文件，接下来依次对其进行添加暂存区、提交本地库操作。
然后查看hello.txt，发现成功修改。如下图：（注意此处修改的是hot-fix分支下的hello.txt）
同时磁盘里的文件内容也被修改，如下图：
注意：
此处修改的是hot-fix分支内容，master分支内容依旧不变。
④合并分支
如我们对代码进行修改之后，需要把hot-fix分支合并到master分支上，如何操作？
肯定先要切换到master分支，执行合并命令。
- 先切换回master分支。
- git merge 分支名： 把指定的分支合并到当前分支上
⑤冲突合并问题
冲突产生的原因：
合并分支时， 两个分支在同一个文件的同一个位置有两套完全不同的修改。Git 无法替我们决定使用哪一个。必须人为决定新代码内容。
比如，我们先在master分支下，通过vim hello.txt。修改文件（倒数第二行增加一些内容）。如下图：
然后老套路：添加暂存区、提交本地库。
接在切换到hot-fix分支，----- git checkout hot-fix
修改文件（倒数第一行增加一些内容），如下图：
切换到master分支，分支合并----- git merge hot-fix
此时日志提示在hello.txt里产生了冲突，自动合并存在问题。
此时再通过git status查看本地库状态。如下图
日志提示两个分支都对此文件进行了修改，此时Git无法判断保存哪一个。因此产生冲突。
因此为了解决冲突需要我们手动合并代码。
先vim hello.txt打开文件，发现文件中已经标出了哪一块发生了冲突。如下图。
以上两块代码都做了修改，合并冲突，需要手动去掉不需要的内容。
保留添加的内容，保存退出即可。如下图：
此时冲突已经解决，但不要忘记：添加暂存区、提交本地库。
但要特别注意的是，此时提交本地库的时候不可以加文件名，否则会报错。因为两个分支都修改了hello.txt，并且处于合并状态没有终止。如果带文件名就会报错。如下图。
此时提交本地库的时候不加文件名，可以提交合并成功
此时再查看 cat hello.txt，
发现成功解决合并冲突，达到了想要的合并效果。
注意：合并只会修改master分支的内容，hot-fix分支的内容不会被修改。
验证：切换到hot-fix 分支查看，发现确实如此。
6，Git团队协作机制
6.1，团队内协作
举例分析团队内协作：
作为华山派掌门人，岳不群在他的本地库里开发了一套《华山剑法》，开发完成之后岳不群总感觉此剑法差点火候，所以想让自己的大弟子—令狐冲帮忙完善一下剑法中的中的细枝末节。
于是岳不群使用push命令把自己的《华山剑法》推送到代码托管中心（如github、gitee），于是代码托管中心多了一个远程库，接到师傅命令后，大弟子令狐冲立刻把远程库clone克隆（完整复制）到自己的本地库中去。
经过多天苦苦完善后，令狐冲把自己完善后的版本push到了远程库里，岳不群就可以使用pull命令拉取远程库里的代码，更新自己的本地库。
最终得到终极版的华山剑法！！！
当然，他们需要是同一个团队才可以向此远程库push代码.
6.2，跨团队协作
举例分析跨团队协作：
作为华山派掌门人，岳不群在他的本地库里开发了一套《华山剑法》，开发完成之后岳不群总感觉此剑法差点火候，所以想让自己的大弟子—令狐冲帮忙完善一下剑法中的中的细枝末节。
令狐冲一看，感觉十分头大。这么高深的剑法只有东方不败大佬才能进行优化。但东方不败不是我们团队里的，而且作为堂堂日月神教教主，东方不败肯定不愿意来我们华山派这个小团队。于是和东方不败进行了跨团队协作。
于是，东方不败就开始工作。他先在代码托管中心里把岳不群的远程库fork（叉过去）到自己的远程库里边，接着东方不败把自己的远程库内容clone到本地库，开始修改华山剑法，经过多天努力，在本地库里共提交了三个版本，最终选择v3版本，于是将其push到东方不败自己的远程库里。
接下来的工作就是，把远程库的内容发送给岳不群。东方不败需要先发送一个pull request请求给岳不群，告诉岳不群：修改好了，已经可以拉取了。
岳不群心想：不急，我要先看看你的代码，如果真比我的原版好。我岳不群直接拉取，无话可说。这时岳不群就先对修改内容进行审核，审核完成之后惊叹道：不愧是东方不败大佬，修改完的版本也太强了吧！于是把东方不败修改的代码和自己的代码进行merge合并。之后岳不群就可以把远程库里的内容通过pull拉取到本地库。
这时岳不群就可以修炼已经修改好的《华山剑法》，和岳不群同处一个团队的令狐冲也可以修炼此剑法。
本笔记根据尚硅谷Git视频教程整理。大家可以点击下方链接进行学习，内容若有不当之处也欢迎大家批评指正。
链接:
https://www.bilibili.com/video/BV1vy4y1s7k6?p=20&vd_source=0a6f87040fc9bf2f899ff136b4df18bf