1. 分支管理
1.1 合并模式
1.1.1 fast forward模式
git log --graph --abbrev-commit
1.1.2 no-ff模式
合并出现问题后需要进行手动修改：
如下图所示：
1.1.3 不使用no-ff模式
git merge --no-ff -m "merge dev2" dev2
1.2 分⽀策略
在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理： ⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；
⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布 时，再把dev分⽀合并到master上，在master分⽀发布1.0版本； 你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就 可以了。 所以，团队合作的分⽀看起来就像这样：
1.3 bug 分⽀
假如我们现在正在 dev2 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要 解决。
在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀ 删除。 可现在 dev2 的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？
情况：分支开发了代码还未提交，master出现了bug；
我们切回到master分支，查看状态发现我们的工作区的文件没有保存；重新切回到dev2分支，将工作区的文件进行储存；
git stash
如下所示，我们dev2分支的内容就存储到stash里面了；
此时我们的工作区里面比较干净；但是我们的readme虽然没有进行add操作，但是已经被git所追踪管理；
此时来修复bug：首先进入到master创建bug分支，其次在bug分支里面进行对readme文件进行修改，add和commit操作之后回到master分支进行合并；
此时回到dev2分支继续进行开发，发现之前的内容被放到stash里面了，所以我们要进行会发到从前的状态，
git stash list//查看stash里面有哪些内容
git stash pop//将stash里面的内容恢复回来
此时对dev2分支中的内容进行提交了；
此时的分支如下：
如果让dev2合并到master分支上，则可能会出现冲突，如下所示：
我们进行如下操作：
第一步：
在dev2分支上进行合并master，然后解决冲突之后，最后回到master，合并dev2分支，此时的合并就没有问题了；
第二步：
1.4 强制删除本地分支
git branch -d//只有在进行merge之后，才能使用该指令；
我们做如下修改： git branch -D 分支名
2.远程操作
2.1 理解分布式版本控制系统
我们⽬前所说的所有内容（⼯作区，暂存区，版本库等等），都是在本地，也就是在你的笔记本或者 计算机上。⽽我们的 Git 其实是分布式版本控制系统！
可以简单理解为，我们每个⼈的电脑上都是⼀个完整的版本库，这样你⼯作的时候，就不需要联⽹ 了，因为版本库就在你⾃⼰的电脑上。既然每个⼈电脑上都有⼀个完整的版本库，那多个⼈如何协作 呢？⽐⽅说你在⾃⼰电脑上改了⽂件A，你的同事也在他的电脑上改了⽂件A，这时，你们俩之间只需 把各⾃的修改推送给对⽅，就可以互相看到对⽅的修改了。
分布式版本控制系统的安全性要⾼很多，因为每个⼈电脑⾥都有完整的版本库，某⼀个⼈的电脑坏掉 了不要紧，随便从其他⼈那⾥复制⼀个就可以了。
在实际使⽤分布式版本控制系统的时候，其实很少在两⼈之间的电脑上推送版本库的修改，因为可能你们俩不在⼀个局域⽹内，两台电脑互相访问不了。也可能今天你的同事病了，他的电脑压根没有开 机。因此，分布式版本控制系统通常也有⼀台充当“中央服务器”的电脑，但这个服务器的作⽤仅仅 是⽤来⽅便“交换”⼤家的修改，没有它⼤家也⼀样⼲活，只是交换修改不⽅便⽽已。有了这个“中央服务器”的电脑，这样就不怕本地出现什么故障了（⽐如运⽓差，硬盘坏了，上⾯的所有东西全部 丢失，包括git的所有内容）；
中央服务器也叫做远程仓库；github就是远程仓库，国内有平替版本的gitee码云；
2.2 创建远程仓库
点击创建：
新建issue：
当我们的仓库开源之后会有人发现我们代码的bug有问题，所以会通过issue给仓库的成员提出问题，如下：
关于pull requests：
开发者在dev分支开发完成后，要向管理者提交（pr申请单），等申请通过之后才能进行合并；
2.3 克隆远程仓库
1、使用https协议
复制https连接，将远程仓库复制到本地文件中来：
git remote
git remote -v
查看远端的详细信息；
2、使用ssh协议：
点击设置：
使⽤ SSH ⽅式克隆仓库，由于我们没有添加公钥到远端库中，服务器拒绝了我们的 clone 链接。需要 我们设置⼀下：
第⼀步：创建SSH Key。在⽤⼾主⽬录下，看看有没有.ssh⽬录，如果有，再看看这个⽬录下有没有 id_rsa 和 id_rsa.pub 这两个⽂件，如果已经有了，可直接跳到下⼀步。如果没有，需要创建 SSH Key：
ssh-keygen -t rsa -C "1533722647@qq.com"
现在有了那两文件，返回上一目录是cd ..
此时拿到公钥之后就要配置到码云平台上了：
复制公钥内容到：
复制ssh协议：
2.4 推送
一般来说，我们本地仓库是进行操作和修改文件的，我们要把文件推送（push）到远程中央仓库，详细俩说就是将本地仓库中的master分支（只要是分支都可以），推送到中央仓库的master（也可以是其他分支）分支上；push就是分支和分支的交互；
在推送之前确保我们的配置是一样的；
在克隆下来的远程仓库中进行文件创建，add和commit；
使用push来完成交互；
git push origin master:master（本地分支：远程分支）；
如果本地和远程的交互分支的名字都一样的，上面语句可以修改为如下所示：
git push origin master
结果如下：
2.5 拉取远程仓库
一般来说中央仓库里面的内容先进与本地仓库，本地就要将中央的文件拉取到本地进行操作；
直接在gitee中进行修改：
git pull origin master:master（中央仓库：本地仓库），同时如果两个分支一样的话可以进行简写；
pull操作：
1、将中央仓库的分支文件拉到本地
2、将地方的文件直接覆盖，即直接合并到本地的分支上；
2.6 配置git
在⽇常开发中，我们有些⽂件不想或者不应该提交到远端，⽐如保存了数据库密码的配置⽂件，那怎 么让 Git 知道呢？在 Git ⼯作区的根⽬录下创建⼀个特殊的 .gitignore ⽂件，然后把要忽略的⽂件 名填进去，Git 就会⾃动忽略这些⽂件了。
不需要从头写 .gitignore ⽂件，gitee 在创建仓库时就可以为我们⽣成，不过需要我们主动勾选⼀ 下，简单来说就是有的特殊文件不想让git来追踪管理，我们就把这些文件放入到gitingnore文件中：
由于我们在初始化的时候没有勾选gitingnore文件，所以要在本地仓库来进行手动创建一个；
如上所示所有.so文件都无法进行追踪管理；
如果我们想让.so文件的有些文件强制被追踪管理；
使用下面指令-f：git add -f b.so
但是我们不建议使用该文件，我们应该在giyignore文件里面进行修改：
在文件里面添加!c.so,即排除这个文件；
查看d.so被忽略的指令在那里
接下里把刚写好的文件推送到远端去：
-----------------------------------------------------------------------------------------------------
设置全局配置项别名：
给git status起别名：
git config --global alias.st status
git st:
git log --pretty=oneline --abbrev-commit打印提交的漂亮的日志
设置为段指令：
git config --global alias.lpa 'log --pretty=oneline --abbrev-commit'
即git lpa
2.7 标签管理
标签 tag ，可以简单的理解为是对某次 commit 的⼀个标识，相当于起了⼀个别名。例如，在项⽬ 发布某个版本的时候，针对最后⼀次 commit 起⼀个 v1.0 这样的标签来标识⾥程碑的意义。
相较于难以记住的 commit id ， tag 很好的解决这个问题，因为 tag ⼀定要给⼀ 个让⼈容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使⽤标签就能很快定位 到。
对最新的一次提交进行打标签为v1.0；
也可以对之前提交进行打标签，只不过是要进行添加commit id；
如下：
标签的顺序是按照英文的顺序来进行排序的；
对标签进行描述打标签：
git tag -a v0.8 -m"ipmport tag v0.8" xxxxxx;
查看描述信息：
删除标签：
git tag -d v0.9
2.8 推送标签
将本地的标签推送到远程仓库：git push origin v1.0
推送所有标签：
git push origin --tags
论如何将本地的删除标签结果推送到中央仓库：
git tag -d v1.0
git push origin :v1.0
ps：本文到这里就结束了，谢谢观看！！！
