git学习笔记——开发中会一定用到的git知识全面整理

本文链接：https://blog.csdn.net/A_rookie_in_HUST/article/details/130475486

首先附上本篇笔记的git地址，可在此处下载pdf版笔记和笔记内的所有测试用例：https://github.com/ZengJiayi549/gitLearn

如果连本地操作和分支概念都不熟，就先在这几篇入个门~

【必看】https://mp.weixin.qq.com/s/Hyb2qoL7uKVUVXeme05K3g

【必看】https://mp.weixin.qq.com/s?__biz=MzU0OTE4MzYzMw==&mid=2247491939&idx=3&sn=76ad3a55a96c6f28e8ee354cfe938ed3&chksm=fbb1689dccc6e18b0542449d56b64718e351208bb4b63f897691b7f482634d7375b3f74807f7&scene=27

【必看】https://www.javaclub.cn/tool/60847.html

https://blog.csdn.net/m0_48651355/article/details/120646834

分支管理、合并冲突与解决、拉取推送到远程仓库的冲突与解决

git-merge时到底发生了什么？

一般来说，如果有两个本地分支例如master和dev，未完成开发时始终保持dev提交的指针在master前，master不要有新的提交。dev上完成开发后，切换到master分支【git checkout master】，再执行合并分支的命令【git merge dev】，这样master和dev就合并成功，新的提交节点版本中，有master基础上dev更新的内容（这种情况属于Fast-forward，一定不会产生合并冲突），master后移到和dev指向同一个commit节点。然后本地的dev分支就可以删了。

参考博客：

【必看】详解git merge命令应用的三种情景_相关技巧_脚本之家 (jb51.net)

git merge 的三种情况 - 知乎 (zhihu.com)

merge合并产生的冲突什么时候会发生？

只要两个分支都分别提交了若干次（也就是不属于上述Fast-forward的情况），且merge时同一个文件同时被两个分支的commit修改，就会产生冲突（除非在两个分支修改后同一个文件内容还是一模一样的）；如果修改的是不同文件，就不会产生冲突。

在这里插入图片描述

merge合并产生的冲突怎样才算解决？

git merge如果发生上述情况的冲突后，git会自动把冲突文件的冲突之处变成这种形式：
在这里插入图片描述

这时候只要修改了文件（甚至你不修改，直接留下这些奇怪的符号也行）并git commit一次，冲突就算解决了并合并成功了，此时合并后的提交树是这样的：
在这里插入图片描述

至于怎么修改，保留哪部分，完全看你自己，git是不会管的。vscode中给了几种合并冲突的策略供参考，但其实也可以不管他，自己直接随便改。
在这里插入图片描述

参考博客：

详解git merge命令应用的三种情景_相关技巧_脚本之家 (jb51.net)

(19 封私信 / 8 条消息) Git到底什么情况下会产生合并冲突？ - 知乎 (zhihu.com)

本地开发完一版新代码需要推送到远程仓库，但远程仓库也被别人更新了一版新代码，此时需要先拉再推【git pull (或git fetch -> git merge origin/master) ->解决冲突->git push】如何理解整个流程？

由于git pull就是git fetch + git merge origin/master，这里只分析git fetch、git merge origin/master和git push

以主分支master为例，首先需要理解“远程仓库的分支master、本地的远程分支origin/master、本地的分支master”之间的关系，才能明白git fetch到底干了什么

先看这篇：

【必看】(92条消息) git 远程分支与本地分支_本地分支和远程分支_滨边美波她男友的博客-CSDN博客

重点总结：

git branch -vv 用于查看本地分支(e.g. master)和本地的远程分支(e.g. origin/master)的关系，注意origin/master的内容不会随着真正远程仓库master的内容改变，需要git fetch才能把这两个内容同步

git branch -a用于查看有哪些本地分支和本地远程分支

git remote show origin命令通过连接网络，去获取本地分支与真正的远程分支的关联情况

再强调两个地方：

本地的远程分支origin/master和远程仓库中的master分支是两个不同的分支，因此origin/master中的内容不一定是git仓库里最新的内容；获取远程仓库最新的内容到origin/master需要靠git fetch命令。
本地的远程分支origin/master和本地分支master也是两个不同的分支，还是得按分支合并那一套才能同步两个分支的内容。git push时一般是推送master的内容到git远程仓库的master分支。

先从远程仓库拉代码到本地，解决冲突+合并后，再推送到远程仓库的最标准的流程如下：

【git fetch origin master:master】同步本地的origin/master分支和远程仓库的master分支；相当于origin/master有了一次最新提交
【git checkout master】切换到本地的master分支，【git merge origin/master】将origin/master的最新内容合并到master分支（这时候可能会有merge冲突。修改冲突之处后，再【git commit】一次冲突解决；此时master分支有origin/master中的新内容，也有本地更新的内容）
【git push origin master:master】将master分支上“在远程更新内容的基础上更新的本地内容”推送到远程仓库的master分支上

详细过程图解：

一、origin/master: ahead 2的意思是，距离上次把master 分支push上远程仓库，master已经有了两个新的提交节点，可以再次push了。注意：不要手动在origin/master分支merge master，这是没有意义的。就算两个指针一致了，还是会显示ahead。只有push成功了才会重新同步，不显示ahead
在这里插入图片描述

git push后：

在这里插入图片描述

二、origin/master:behind 2的意思是，远程仓库分两次改动了某些文件，并且分别fetch了两次到本地的origin/master分支上，但是此时的origin/master分支的内容并没有和master分支的内容合并，还需要【git checkout master】切换到本地master分支，【git merge origin/master】将origin/master的内容合并到master分支；master指针后移一个commit
在这里插入图片描述

git checkout master, git merge origin/master后：
在这里插入图片描述

三、如果在本地origin/master与本地master进行merge之前，master已经有过和远程主机改动同一文件的commit操作，会导致本地origin/master与本地master的merge产生冲突，需要手动修改（怎么修改，修不修改都不重要，重点是要再git commit一次）并【git commit】一遍来解决
在这里插入图片描述

例如改了2次，文件变更且fetch了1次，这种情况只要本地和远程修改了相同的文件（只要不是修改后的内容还一模一样）就会产生冲突
在这里插入图片描述

手动修改冲突之处，再【git commit】就解决冲突并merge 了master和origin/master
在这里插入图片描述
此时master和origin/master已经在本地同步，远程也要同步的话，需要【git push】将master的内容推向远程仓库。这时由于远程主机没有再commit了，所以push是肯定不会有冲突的。至此，整个远程代码与本地代码同步->本地代码推送到远程仓库加上解决冲突的过程就结束了。