1.什么是git
git就是 分布式 版本控制 软件
软件：git也应该是从别的地方下载下来安装到我们电脑上的软件。
版本控制：跟毕业论文一样，先写好版本1然后交给导师，导师说不行，然后再改为版本2，然后循环下去，这就是版本。写论文的时候我们用的是拷贝文件的方式来做版本控制。
版本控制经历了4种发展状态：
1、文件拷贝方式，例如论文
2、为本地版本控制，对比于1的方式，本地版本控制在本地只会看见一个文件，在这个文件的背后通过这个本地版本控制软件把以前所有的版本都给你保存起来了。类似于打游戏的存档，你是看不见的，而是偷偷的给你存到某个地方去了。以后你想回到某个版本，只需要通过软件或者某个命令即可回到指定版本。对比1的方式，进步的点有电脑上不会看到那么多的文件了
3.集中式的版本控制
他会把所有的版本存到集中式的服务器中。集中式的本地是无法保存版本的，只能推到中心上去，缺点就是中心服务器挂掉了就没办法了。代表的软件有：svn
4.分布式版本控制
优点就是即使中心服务器挂掉了也没关系，我们自己的电脑上有一份，我就在自己的电脑上用，以后弄了个新的中心服务器，我可以把本地的版本全都推上去。相当于把版本分布的放在每一台电脑上都拷贝了一份，即使某一个单点故障了，它都不影响咱们代码的完整性。
2.git的作用
用于回滚。比如线上功能不行，要删掉的时候，我们可以快速回滚代码。
3.git的安装
git软件只需要安装在本地，则可以在本地完成v1，v2，v3的版本控制。如果想在中心也有，就需要在类似github的网站上存储。
linux，mac，win系统的安装方式均不同。linux和mac可以通过命令安装，而win可以下载安装包进行安装。
这里省略。可以去官网查看安装。
4.git管理文件的逻辑
- 先进入要管理的文件夹
- 初始化这个要管理的文件夹 git init
- 添加要管理的文件 git add .
- 生成版本 git commit -m 'v1'
其实在第四步之前应该有一个配置个人信息的步骤[仅需要在最开始的时候执行一次即可]
- git config --global user.email "[email protected]"
- git config --global user.name "Your name"
如果后续我们修改了要管理的文件夹里面的文件，我们在生成新的版本
git add .
git commit -m 'v2'
查看全部版本记录
git log
5.git三大区域
6.git回滚
回滚至之前的版本：
git log 查看版本
git reset --hard 版本号 进行回滚
如果我们还想回到约饭功能需要用到新的命令
回滚至之后的版本
git reflog
git reset --hard 版本号 进行回滚
7.git的分支
分支的作用：分支可以给使用者提供多个环节的可以，意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。
新建分支会通过指针指向master上的版本
举个例子，原来项目里面有100个文件，我们后来修改了10个文件，新增了20个文件。
在git中的体现就是有c1版本变成了c2版本，而c2版本只保留了新增及发生变化的文件，而90个未修改的文件在c2版本里面不会被保存。
那么如果在c2与c1之间创建联系呢？就存在指针这个东西。c2版本是指向c1的，以后我们拿c2的版本，就会在c2中拿对比c1有变化的文件及通过指针再拿c1里面没有变化的文件。这也就保证了存储空间及速度更快。
随着时间的推移我们又新开发了一个版本c3，c3是在c2的基础上发生变化，所以c3里面也会保留自己更改的部分，而没修改的部门还是通过指针的形式指向了上一个版本即c2。
分支的应用场景：
比如我们现在在开发网站的新功能，但是开发到一半的时候，线上的网站出现了bug，这个时候我们应该把开发一半的功能暂存起来，来修复线上的bug。这就用到了分支来暂存。
主干线叫master
分支的名字可以随便定义。
分支相当于创建了一个相互隔离的环境，不影响master，而在分支开发完成后需要合并到master上面的。
查看目前你所处在的分支
git branch
创建新的分支
git branch 分支名
切换分支
git checkout 分支名
注意切换分支是不影响master的。
现在我们在dev分支修改了代码，可以看下图的git变化，我们添加并提交分支内容
可以看到下图，c4版本是dev分支的。
这个时候我们切换到master ，
git checkout master
会发现刚才在dev分支修改的内容不见了，切换回dev分支修改的代码又回来了。
按照之前上述讲的场景逻辑，我们在dev分支里面开发了一半，这时候线上代码有bug，我们要修复bug，我们需要新创建一个分支名为bug
然后我们修复bug
上图即为在bug分支里面bug已经修复完毕，我们默认master分支是线上代码。所以我们要把bug分支合并到master里面。
想要合并分支：
- 第一步：切换回master分支，相当于站在master上把bug分支的代码拉过来
- 第二步：合并分支，git merge 分支名
- 第三步：如果合并完分支，该分支没有用了就可以删除了 git branch -d 分支名
到此线上bug已经修复完毕，我们回到之前开发一半代码的dev分支继续开发。
注意：dev分支是由创建dev分支时候的master版本作为指针的，所以dev分支是没有刚才咱们修复线上bug的代码的。
但是先不用管，我们这个dev分支就是用来开发新功能的，我们继续开发，现在开发完毕，我们提交。
我们需要合并分支，所以先切回master，进行合并
注意上图：报了一个错，叫冲突，此时在代码里面会显示两个版本的代码变化，如下图，因为git不知道怎么为你解决，所以我们只能手动找到这个文件，把冲突解决了。产生冲突的原因是因为我们的dev和bug分支都来自同一个master版本，而bug在解决完的时候已经合并到了master分支里面并产生了新的master版本，而后我们在合并bug分支的时候，由于master版本有了变化且在同一行代码处做了修改则才会产生冲突，所以才需要手动解决。
解决完了之后我们需要提交新的版本
最后的分支结构图如下：
8.github
github是代码托管的网站，是可以和git做无缝衔接的。
git是一个软件。
除了github网站外还有gitlab网站等
github是网站，gitlab是开源的工具，支持自己的公司搭建一个代码托管仓库。
如果想让github帮你托管，需要做以下几件事
- 注册github账号
- 创建仓库
- 把本地代码推送到github的仓库，如果本地有v1，v2，v3版本，那么这三个版本都会在github上存储。如果有分支也会在github上保留分支。
9.基于github做代码托管
首先在github上创建一个仓库，建议仓库名和代码有关。
勾引 Initialize 则会创建一个readme文件，用来介绍这个项目是干什么的
下面的.gitignore则是让git忽略掉文件夹里面的文件
license则是许可证，就类似于别人看到你的许可证里面写的，你可以拿去学习，但是不能商用的说明。
创建之后github会有一些命令提示/
origin可以代指github的地址。
git push就是把本地的master分支推送到github上。
如果推送dev分支则写git push -u origin dev
github和本地的git托管的格式是一摸一样的。
我们现在本地有代码则可以直接使用
git remote add origin github仓库的地址
git push -u origin master
注意这里可能会需要你输入github的账号和密码。
我们还可以推送dev分支到github上
把github上的代码克隆到本地
git clone github上的仓库地址
查看分支的时候发现从github上clone下来的没有dev分支，其实不是的，只是没有显示。但是我们可以直接切换分支
紧接着我们在本地编写代码，编写完成需要推送到github
向远程仓库推送代码
git push -u origin 要推送的本地分支名称
我们换到最前的电脑，继续开发，就需要先同步github上的代码，所以
从远程仓库拉代码到本地
git pull origin 远程仓库的分支
注意：只有从无到有的才clone，已经存在部分代码，需要更新本地代码，则需要用此命令。
接着开发，然后我们需要再推送到github上，
项目开发完了。
github远程分支的合并，可以在本地的git库先合并好，然后再推送到github的master分支上。
git checkout master
git merge dev
git push origin master
10.忘记推送代码，而产生冲突
由于在公司写了一半的功能，但是没有推送到github上，
导致回到家中拉去代码的时候发现公司写一半功能的代码没有了。
所以我们可以在家中写新的其他功能，写完我们提交到github上。
第二天我们到公司，第一步应该说是拉在家写的代码，但是本地写一半功能的代码怎么办呢？这里再拉在家写的代码的时候就是合并，合并就会产生冲突。有相同的部分就会冲突，就要手动解决冲突。
下面是代码模拟实现。
跳过一些在家写代码及上传到github的步骤，直接演示在公司开发的情景。
由上图可知在pull的时候a1产生了冲突。因为我们在公司改过a1，在家里也改过a1，他们改的是同一行就可能产生冲突。
我们手动介入解决冲突。然后可以提交到github。
11.git rebase
rebase的中文叫 变基
主要功能是让你的代码提交的git记录变得简洁。
应用场景可以分为三种。
场景一：
假如老板布置了一个很大的任务，我们需要五天来开发完，所以我们每天都会提交新版本，这些版本对我们自己是有意义的，但是对于老板是没意义的，老板只要最初始的代码和第五天开发完成的代码。所以我们需要rebase，rebase可以把多个提交记录整合为一个提交记录。
下面是代码还原场景演示
看上图可知我们现在有4条提交记录。现在我们想把某些记录整合为一条，
方式一：
git rebase -i 版本号
注意：git就会把我们现在所在的地和v2所在的版本的中间这三次记录做合并
方式二：
git rebase -i HEAD~3
从当前开始找最近的3条记录，让这3条记录进行合并
回车执行，会显示如下：
我们把v3和v4变成s
其中s就是，让当前这个s版本合并到他上一个版本去。最后就是 v3和v4都会合并到v2
写完之后需要保存，
:wq
出现下图，让我们填写合并信息的。
我们可以按照下图进行填写，
然后再 :wq
最后就变成下图所示即为完成
注意事项：
在做记录合并的时候，切记，如果某个版本已经push提交到远程仓库了的记录，最好不要把该记录做rebase合并，尽量合并的是那些没有提交到版本库的记录。因为如果你搞了之后，接下来在rebase，远程仓库有记录，你本地也有记录，两个历史记录不一样就会很麻烦。但是也能做，但是在这里不建议这样。
场景二：
gitrebase可以把c3版本的提交记录归并搭配master上去。
我们把dev分支合并到master上面。
或者用git log --graph 显示版本日志
或者用 git log --graph --pretty=format:"%h %s"来进行简化
h代表哈希值，s代表提交的一个记录
先切换到dev分支，然后rebase master
然后切换回master分支，再把dev分支给merge回来就ok了
场景三：
在三里屯写了v1版本，但是没有上传，然后在家里又开发了v2版本上传到github了。转天回到三里屯要从github上下载代码到本地，就会产生合并，合并就会产生分叉。
不产生分叉就需要这么做：原来我们从github上下载代码是用的git pull。现在我们不用git pull，用git fetch命令。
之前咱们说过git pull等于git fetch + git merge
现在我们不用merge了，我们用git rebase
总结：
我们由原来的 git pull origin dev 变成了
git fetch origin dev 然后紧接着执行
git rebase origin/dev
总结：
注意事项：
如果git rebase 的时候，可能会产生冲突，如果产生冲突，别着急，产生冲突会告诉我们，我们继续解决冲突。解决完冲突会告诉我们继续执行 git add...等等的命令，然后再告诉我们要执行git rebase --continue
continue是继续的意思。
实例：
我们先切换到dev分支。编写1.py文件
然后切换到master分支也编写相同的1.py文件
然后我们到dev分支执行git rebase master 就会报错了。
出现上图报错，告诉我们有冲突，现在处于git中断的状态。
然后我们手动解决冲突，修改1.py文件。
所以看上图，我们也rebase完成了。
12、beyond compare软件快速解决冲突
现在我们先模拟冲突，如下图
以前我们是找到冲突的文件手动解决，现在我们用beyond compare工具就不用手动解决了。
1.首先安装beyond compare软件
2.在git中配置：
git config --local merge.tool bc3
git config --local mergetool.path '/usr/local/bin/bcomp'
git config --local mergetool.keepBackup false
merge就是合并的意思，tool是工具。第一行命令就是合并工具起了个名叫bc3
第二行命令的意思就是这个工具的路径在哪
第三行名的意思是，让beyond compare软件帮我们解决冲突的时候不用保留备份了。就是源文件不用保留了
--local的意思是：只对当前项目有效
3.应用beyond compare解决冲突
git mergetool
执行上面的命令，beyond compare就会自动运行起来。
解决完点保存就行。这样就不用vim去解决了。直接，明了。
9、git常用命令
初始化
让git帮助我们管理当前文件夹
git init
检测当前目录下文件的状态
即是否被git管理。
git status
把没有被git管理的文件，让git把它们管理起来
git add .
生成版本
git commit -m 'v2'
查看版本
git log
以图形显示版本
git log --graph
简化图形显示版本
git log --graph --pretty=format:"%h %s"
h代表哈希值，s代表提交的一个记录
回滚至之前的版本
git log 查看版本
git reset --hard 版本号 进行回滚
回滚至之后的版本
git reflog 查看版本
git reset --hard 版本号 进行回滚
三种状态的变化
- 红色：新增的文件/修改了原老文件 -> git add 文件名 或者 .
- 绿色：git已经管理起来了 -> git commit -m '描述信息'
- 生成版本
把已修改文件变成修改之前的状态，即还原文件
git checkout -- 文件名
把以添加到暂存区的文件回到未添加之前的状态
git reset HEAD 文件名
查看所处分支
git branch
创建新的分支
git branch 分支名
切换分支
git checkout 分支名
合并分支
注意：需要先切换为master分支，再执行merge命令
git merge 分支名
删除分支
git branch -d 分支名
给远程仓库起别名
git remote add origin 远程仓库地址
这里的origin是别名。可以叫任何都行。
向远程仓库推送代码
git push -u origin 要推送的本地分支名称
从远程仓库克隆代码
git clone 远程仓库地址
这里注意，在clone的时候内部其实做了起别名的这件事。默认就叫origin，以后再用直接用这个origin即可，不用再起别名了。
从远程仓库拉代码到本地
git pull origin 远程仓库的分支
注意：只有从无到有的才clone，已经存在部分代码，需要更新本地代码，则需要用此命令。
上面这一句代码等同于两句代码：
git fetch origin dev 把代码从远程仓库先不拉到本地的工作区，而是先拉到版本库
git merge origin/dev 把版本库的代码更新到本地工作区，注意要写 origin/分支，因为会加一个远程仓库的前缀
合并git提交记录
方式一：
git rebase -i 版本号
注意：git就会把我们现在所在的地和v2所在的版本的中间这三次记录做合并
方式二：
git rebase -i HEAD~3
从当前开始找最近的3条记录，让这3条记录进行合并