一、分支
1.git中如何保存版本
在我们以往使用文件来进行版本控制的时候，都是将上一个版本复制一份，然后在其基础上进行修改。
但在git中，git只保存当前版本和上一个版本之间的差异，这样可以节省存储空间， 在生成版本的时候速度也会更快。
2.Master主线
如下图所示：
当只有一条主线Master时，新版本都是在上一个版本的基础上进行修改的，例如Version2在Version1的100个文件基础上，新增了20个文件，并修改了其中10个文件。
也就是说Version2只需要保存新增的20个文件，以及修改的10个文件的修改信息，当我们需要Version2的时候，git再去Version1中拿未修改的90个文件。
同理，Version3、Version4也是如此。
3.分支概念
当我们需要已某个版本作为基准，同时开发多个新功能，则可能在该基准版本处产生分支，如下图所示：
处理线上系统的紧急BUG：
例如，Version3是已上线的版本， 我们在Version3的基础上开发新功能：
Version3突然出现紧急BUG，需要修复，怎么办？我们可以在Version3的基础上新开一个分支，专门用作BUG修复，修复完后合并到主分支：
而负责新功能开发的分支，可以继续研发新功能，不受影响。等到新功能开发测试完毕后，也可以合并到主分支Master中去。
4.创建分支（开发新功能）
1)查询分支信息
git branch
可以看到，我们目前只有一个master主分支。
2）创建新的分支（开发商城功能）
git branch dev_shop
使用命令创建了一个分支，叫做dev_shop。用于开发新功能，商城。
"*"号代表我们所处的分支。
3）切换分支
使用命令：
git checkout dev_shop
可以看到，我们已经切换到了dev_shop分支，我们在这个新分支下编写代码，是不会影响到其他分支的。
通过git log查看一下版本信息：
可以看到，我们所处的版本是"修改约饭-->约"，但是分支处于dev_shop。而在这个版本处存在两个分支：master和dev_shop。相当于下图所示：
如果我们在dev_shop分支上再生成一个版本，则会变成如下：
在分支中添加了商城功能后，使用git log查看版本信息：
5.创建分支（修改BUG）
1）切换回master分支
git checkout master
2）创建新分支（修改BUG）
git branch bug
查看分支：
git branch
3）切换到BUG分支
git checkout bug
修改代码：
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Index</title> </head> <body> <ul> <li>欧美</li> <li>日韩</li> <li>港台澳</li> <li>直播</li> <li>约</li> </ul> </body> </html>
将"港台"修改为"港台澳"。并提交生成新的版本。
此时查看git log：
此时的分支结构为：
6.合并分支
将bug分支合并到master分支中。
1）切换回master分支
git checkout master
2）合并bug分支
git merge bug
查看当前的版本信息：
当前的分支结构：
7.删除分支
当Master分支将bug分支合并之后，bug分支就没用了，可以使用命令删除bug分支：
git branch -d bug
删除后，查看当前分支信息：
可以看到bug分支已经被删除。
8.继续开发dev_shop
1）从Master切换到dev_shop
git checkout dev_shop
2）继续开发dev_shop，并提交
9.将dev_shop合并到Master中
1）切换回Master分支
git checkout master
2）合并dev_shop分支
git merge dev_shop
当合并的时候，如果没有冲突（例如都是添加代码），则可以自动合并。
自动合并后会生成一个新的版本：
如果产生了冲突（例如修改了同一行代码），则自动合并失败。
当产生冲突的之后，git会将两个文件所修改的地方全部放在文件中，然后由我们人工进行处理：
我们人工修改为最终版本后，再次进行git add 、 git commit操作，重新提交即可。手工生成的版本信息，由我们自己指定。
二、分支总结
1.查看分支
git branch
2.创建分支
git branch 分支名
3.切换分支
git checkout 分支名
4.合并分支
git merge 分支名
注意，假设分支2要合并到分支1中，则需要切换到分支1中执行"git merge 分支2"。
三、简单工作流
git中默认有一个master分支，但是不建议我们直接在master分支上去做开发，master分支主要用于保存正式版本（稳定版本）。
我们开发新的功能，都应该去一个单独的分支上去做开发。例如叫dev的分支。如图所示：
从图中可以看到，我们的开发都在dev分支上做，而master分支的版本都是稳定版本。
类似于QQ的稳定版和beta版，稳定版在master分支中，beta测试版在dev分支中。
以上就是最基本的工作流。
四、github
github和git其实没有本质的联系，github只是一个类似于云盘的代码仓库。除了github，还有CSDN、码云等平台也提供类似的功能。
要使用github，需要以下几个步骤：
1）注册一个github账号
2）创建一个仓库
3）将本地代码推送到github仓库
1.注册github账号
（略）
2.创建仓库
Repository name尽量与项目名一致，方便查找。
Description用于描述项目。
Public表示开源（代码公开），Private表示只有自己能看到。
Initialice this repository with a README，自动创建一个README文件。
Add .gitignore表示创建一个不被git管理的文件夹
Add a license表示我们代码的许可证。
3.推送代码到仓库
在我们的项目文件夹中打开git bash窗口，执行命令：
git remote add origin https://github.com/leokale/dbhot.git
origin就是我们要推送的目的仓库的别名。
然后再执行push命令：
git push -u origin master
推送master分支到仓库。
此时会弹出一个用户名密码窗口，用于github验证：
输入账号密码通过验证后，可以看到推送成功：
此时，我们可以在github中看到仓库里存放着master分支的相关文件：
推送dev_shop分支的代码到仓库：
git push -u origin dev_shop
第二次推送，就无需验证github账号密码了。
此时，在github仓库中，可以看到多出了一个dev_shop分支。
4.从仓库拉代码
例如我们在另一台PC上，进入一个根目录（用于存放dbhot项目文件夹）。
在该目录打开git bash：
获取仓库的地址：
使用命令拉取代码：
git clone https://github.com/leokale/dbhot.git
可以看到该目录下出现dbhot文件夹：
进入目录使用git bash即可：
5.github总结
1）给远程仓库起别名
git remote add xxxx 远程仓库地址
2）向远程推送代码
git push -u xxxx 分支名
3）克隆全程仓库代码
git clone 远程仓库地址
当克隆代码之后，实际上帮我们执行了git remote add origin 远程仓库地址。所以我们以后推送的时候，可以使用origin就可以了。
五、局部代码推送与拉取
例如目前的版本结构如下图所示：
当我们要继续在dev_shop分支上去做开发时，发现dev_shop分支的代码不是最新的，因为master分支合并了bug分支和dev_shop分支。所有当前master分支才是最新的。
所以，我们在开发代码之前，首先在本地将master分支合并到dev_shop分支中，让dev_shop分支变为最新代码：
git checkout dev_shop
git merge master
合并后，dev_shop分支中的代码已经变为最新版，也就是和master分支一样，版本为"Merge branch 'dev_shop' "。
1.推送部分代码（在PC-A上的操作）
在dev_shop分支中开发新代码（例如新增一个a1.py文件）：
touch a1.py
保存一个版本：
git add a1.py git commit -m "在PC-A添加了一个新文件a1.py"
推送到仓库：
git push origin dev_shop
此时在仓库的dev_shop分支中可以看到：
2.拉取部分代码（在PC-B上的操作）
首先，切换到dev_shop分支：
git checkout dev_shop
然后，拉取在PC-A上提交的部分代码（a1.py文件）：
git pull origin dev_shop
在a1.py中添加内容：
# a1.py文件 print("HELLO WORLD")
将新的代码推送给仓库：
git add a1.py git commit -m "在PC-B中修改了a1.py" git push origin dev_shop
3.pull命令分解
在git中，git pull命令实际上可以拆分为以下两个命令：
git fetch origin dev_shop
git merge origin/def_shop
git fetch的意思是将dev_shop分支从远程仓库（github）拉回本地版本库。由于拉回版本库，可能和本地的dev_shop不一致，所以名字为origin/dev_shop。
git merge origin/dev_shop的意思是将原来仓库拉下来的dev_shop（origin/dev_shop）合并到工作区。
当然，merge的时候origin/dev_shop分支和本地的dev_shop可能存在冲突（例如PC-A上开发的代码忘了推送，然后在PC-B上又开发了其他代码并推送到了仓库，再在PC-A上fetch下来，就会不一样），需要我们手工解决冲突。
六、查看版本分支结构
1.graph参数
使用git log查看版本结构的时候，可以加上--graph参数：
2.简化模式
git log --graph --pretty=format:"%h %s"
%h：hash值（短）
%H：hash值（长）
%s：备注信息
%an：作者
%ae：作者email
%ad：提交时间
其他格式化字符参考：
git log --help
七、变基（rebase）
变基：git rebase。
有以下三种使用场景。
1.合并多个提交记录
当我们反复在不同的地方开发代码时，可能会经常commit，然后push，这样会生成很多提交记录（版本）。这对于我们自己可能是由意义的，但是对于其他协同开发者是没有意义的。
例如，在某个项目中，我们一共有4条提交记录：
假设，我们想将v2~v4合并成一个提交：
git rebase -i af57743e74ce9f36a8f142e87cd10599b6a36fc4
后面的ID就是v2这个提交的ID。他会将v2~当前提交这三条提交合并成一个提交。
另一种方式：
git rebase -i HEAD~3
HEAD~3是从当前提交往前数3个提交，合并成一个。
执行上述任意一个命令后，会进入以下画面：
我们关注最前面的三行（pick *****），将v3和v4的"pick"修改为"s"：
表示将v3和v4合并到v2中，:wq保存，进入另外一个画面：
修改合并后的commit的描述信息：
:wq保存：
执行git log查看提交记录：
我们可以看到，合并后的commit的时间和v2的时间一致。
2.补充
在执行git rebase HEAD~3命令以后，进入的第一个画面：
我们关注的最前面三行，是分别对三个版本的处理方式：
1）pick：表示使用commit，如果3个版本都是pick，则不发生任何改变，还是v2 v3 v4。
2）reword：同pick，使用commit，但是可以修改备注信息。保存后，会进入修改备注的页面。按r指定的版本，一个一个修改备注。
3）squash：标记为s的版本，会向前合并，例如v4标记为s，则会合并到v3中，以此类推。
4）fixup：和squash很像，但不会进入修改备注的界面，也就是说丢弃标记f的版本的备注信息，并合并到前一个版本中。
5）drop：删除指定的版本。
注意：在使用rebase合并版本时，最好不要是已经push到仓库的版本，最好是合并好后再push到仓库中。
2.将分支的版本合并进master（变成master一条线）
例如，我们目前master有2个版本，分别为m1和m2。
在m1处，创建了分支dev，并且提交了版本d1。
此时的结构如下：
我们如果使用git merge命令，则会将其变为：
但是我们想将其变得更简洁，例如下图：
使用命令：
git checkout dev # 切换到dev分支
git rebase master # 将dev作为base，相当于将master合并进dev
git checkout master # 切换回master
git merge dev # 将dev合并到master
执行上述命令后，master和dev分支的版本都是m1<----m2<----d1。如果不需要dev分支，则将其删除即可：git branch -d dev
3.合并不产生分叉
在《第五节：局部代码推送与拉取》中，我们在PC-A和PC-B上分别开发了代码，PC-A提交在本地版本库，但没有推送到远程仓库。而PC-B的推送到了远程仓库。
当我们在PC-A上pull仓库的代码时，git会帮我们自动进行合并，但可能产生冲突，然后由我们手动解决冲突。
我们知道pull命令可以拆分为：
git fetch origin dev
git merge origin/dev
但是，在这种情况下，一定会产生分叉，因为fetch回来的分支叫做 origin/dev，而本地的叫做dev。
此时，可以使用rebase来代替merge：
git fetch origin dev
git rebase origin/dev
4.rebase时解决冲突
当我们在master和dev分支中都对同一个文件的同一行进行了修改，并都提交到了版本库。我们使用rebase将他们合并成一条分支时，会报冲突错误：
此时，我们可以按照报错提示，去m3.py中查看冲突：
解决冲突：
然后执行命令，继续rebase：
git add m3.py # 处理完冲突后，要使用add加入暂存区或使用rm命令删除
git rebase --continue # 然后继续执行rebase操作
666