目录
git pull和git pull –rebase的区别和使用
两种合并方式（git merge 和git rebase）的区别
git pull和git pull –rebase的区别和使用
使用下面的关系区别这两个操作：
git pull = git fetch + git merge
git pull –rebase = git fetch + git rebase
git pull = git fetch + git merge FETCH_HEAD
git pull –rebase = git fetch + git rebase FETCH_HEAD
差距就在git fetch之后的合并操作，合并操作有两种方式： git merge和git rebase
现在来看看git merge和git rebase的区别。
假设当前master的提交如下：
如果是你或者你的同事在cid2点，开发进度是cid20(或者突然撇出一个分支，假设是tmp分支），此时要把cid20提交到master
在master执行git merge tmp,然后会得到如下结果：
新增了一次提交记录cid6 （合并点）,产生一个megre 记录，甚至没有changID:
commit 8aa716d5f8c550692c4022b965bfda788xxxx1
Merge: c5681f7 86e26b8
Author: xxx<xxx@xxx.com>
Date: Fri Apr 1 14:44:33 2022 -0400
Merge "PN:202203xxx 组合业务拷机，xxx出现断言，……"
似乎也没有什么问题。如果你装了小乌龟，查看提交日志，可能就是下面的样子：
那么来看看git rebase, 在master执行git rebase tmp，操作之后的分支如下：
就像是把tmp分支的后续提交“剪下来”，然后接（按tmp顺序摆放）在master分支后面：
二者对比可知，rebase没有产生新的节点（megre节点），使用rebase的git演进路线(提交树)是一直向前的，这样在版本回退时也很容易，用merge的git路线是跳跃的，如果版本回退你也找不到自己想要的版本，如果在merge时出现了冲突那就麻烦了，当前merge就不能继续进行下去，需要手动修改冲突内容后，add，commit, push.
而rebase 操作的话，会中断rebase,同时会提示去解决冲突。解决冲突后, 再执行 git rebase –continue 继续操作，再push.
想要更好的提交树，建议使用rebase操作会更好一点，这样可以线性的看到每一次提交，并且没有增加提交节点（megre节点）。
不过也有些项目，不建议使用rebase, 这就得看公司与项目的规定。
git pull –rebase的作用是什么，它与git pull有什么区别？：https://blog.csdn.net/yao_hou/article/details/108178717
举例：
现在我们有这样的两个分支,test和master，提交如下：
D---E test
/
A---B---C---F--- master
在master执行git merge test,然后会得到如下结果：
D--------E
/ \
A---B---C---F----G--- test, master
在master执行git rebase test，然后得到如下结果：
A---B---D---E---C‘---F‘--- test, master
链接：https://www.jianshu.com/p/dc367c8dca8e
在rebase的过程中，有时也会有conflict，这时Git会停止rebase并让用户去解决冲突，解决完冲突后，用git add命令去更新这些内容，然后不用执行git-commit,直接执行git rebase –continue,这样git会继续apply余下的补丁。
在任何时候，都可以用git rebase –abort参数来终止rebase的行动，并且mywork分支会回到rebase开始前的状态。
参考或摘抄自：
https://www.cnblogs.com/kevingrace/p/5896706.html
https://www.jianshu.com/p/dc367c8dca8e
https://blog.csdn.net/yao_hou/article/details/108178717
两种合并方式（git merge 和git rebase）的区别
git merge
方式1：
#把master的megre到feature
git checkout feature
git merge master
merge合并的优点：
自动创建一个新的commit，记录了真实的commit情况，方便查看记录
如果合并遇到冲突，仅需要修改后重新commit即可
merge的缺点：就是每次合并都会产生一个新的commit, 所以在使用一些git的 GUI工具，特别是commit比较频繁时，就会看到分支线很杂乱。这时如果有问题需要查找就会很困难。
方式2：
#把master的rebase到feature，就是把master的commit安插到feature线上
git checkout feature
git rebase master
git merge和rebase合并分支的区别：https://www.cnblogs.com/shenjp/p/14437454.html
如上图所示，rebase的特点：
改变当前分支从master上拉出分支
没有多余的合并历史记录，并且合并后的commit顺序不一定按照commit的提交时间排序
可能会多次解决同一个地方的冲突
提交记录更干净，master上每个commit点都是相对独立完整的功能点
假如我们在rebase的过程中遇到了冲突，我们在解决冲突之后，需要执行:
1. git add
2. git rebase –continue 来继续变基的操作。
3. 如果执行第二步无效，那么可以执行 git rebase –skip
注意：不要执行完 git add 之后执行 git commit
git分支合并：https://www.cnblogs.com/alice-cj/p/11300652.html
git reset和git checkout的区别
git的reset和checkout的区别：https://blog.csdn.net/q563573095/article/details/79567430
git的reset和checkout的区别 -SegmentFault ：https://segmentfault.com/a/1190000006185954
已经push到远程仓库的commit不允许reset
checkout指令
checkout指令的作用是：移动HEAD，使其指向某个分支或提交点。如果HEAD切换后的提交点与切换前的提交点不同，则会强制使用新提交点的内容覆盖当前工作区的内容。如果切换前后提交点相同，则不会覆盖当前工作区的修改。
注意：checkout指令，仅仅移动HEAD，不会移动分支名，无论HEAD处于什么状态（分离或绑定）。该指令是
使得HEAD进入分离状态
的唯一指令。（git checkout后会进入 detached状态 from xxx）
reset指令
reset指令的作用是：移动HEAD到指定的提交点。当HEAD处于绑定状态时，会同时移动与HEAD关联的分支名，并保留HEAD的绑定状态。当HEAD处于分离状态时，则只会移动HEAD，不移动分支名。该方法不会强制覆盖当前工作区的内容，除非使用–hard参数。
原文链接：https://blog.csdn.net/aipande143/article/details/114658090
checkout
前面讲到checkout是会修改HEAD的指向，变更Index区域里的内容，修改Working Directory里的内容。
这看上去很像reset –hard，但和reset –hard相比有两个重要的差别
reset会把working directory里的所有内容都更新掉
checkout不会去修改你在Working Directory里修改过的文件
reset把branch移动到HEAD指向的地方
checkout则把HEAD移动到另一个分支
第二个区别可能有点难以理解，举例来说：假设你有两个分支master和develop，这两个分支指向不一样的commit，我们现在在develop分支上（HEAD指向的地方）
如果我们git reset master，那么develop就会指向master所指向的那个commit。
如果我们git checkout master，那么develop不会动，只有HEAD会移动。HEAD会指向master。看图：
git revert 和 git reset区别
reset 就是删除版本链指定版本后面的commit
revert 就是拿指定版本commit到版本链条最后
上图可以看到git reset是会修改版本历史的，他会丢弃掉一些版本历史。
而git revert是根据那个commit逆向生成一个新的commit，版本历史是不会被破坏的。
已经push到远程仓库的commit不允许reset
上面已经讲了，git reset是会丢弃掉commit的。
如果commit已经被push到远程仓库上了，也就意味着其他开发人员就可能基于这个commit形成了新的commit，这时你去reset，就会造成其他开发人员的提交历史莫名其妙的丢失，或者其他灾难性的后果。
因此，一旦commit已经被push到远程仓库，那么是坚决不允许去reset它的。
git的reset和checkout的区别：https://blog.csdn.net/q563573095/article/details/79567430
git pull 和git fetch的区别
git pull = git fetch + git merge
git fetch的作用是将远程分支的数据拉取下来，但是不会主动合并。如下图：
本地git clone 下来数据B0-B1-B2。然后
远程有人提交了C0-C1，本地自己提交了D0-D1，然后git fetch 下来C0-C1，但是不会主动合并：
然后git merge或git rebase就合并：
更详细的说明：
Git：远程分支—-git fetch命令的使用_https://blog.csdn.net/qq_42780289/article/details/98049574