为什么先commit，然后pull，最好在push？

在实习期间，与小组伙伴多人协作时，产生的一些git 操作问题：：解决方案，先git add-》git commit-》git pull-》git push

1.那么为什么先commit，然后pull，最好在push？而不是commit 完push？

.commit是防止远程直接覆盖你本地，只要有修改都会让你commit，提示你pull原因是因为你远程当中有最新的东西和你本地不一致，git知道，远程分支的东西不能丢掉，所以让你pull下来存到本地，让本地变成最新的最后push上去，那么同理的方式你本地就是最新，便会去修改远程的。

 

这个先 commit 再 pull 再 push 的情况就是为了应对多人合并开发的情况,

1. commit 是为了告诉 git 我这次提交改了哪些东西,不然你只是改了但是 git 不知道你改了,也就无从判断比较;

2. pull是为了本地 commit 和远程commit 的对比记录,git 是按照文件的行数操作进行对比的,如果同时操作了某文件的同一行那么就会产生冲突,git 也会把这个冲突给标记出来,这个时候就需要先把和你冲突的那个人拉过来问问保留谁的代码,然后在 git add && git commit && git pull 这三连,再次 pull 一次是为了防止再你们协商的时候另一个人给又提交了一版东西,如果真发生了那流程重复一遍,通常没有冲突的时候就直接给你合并了,不会把你的代码给覆盖掉

3. 出现代码覆盖或者丢失的情况:比如A B两人的代码pull 时候的版本都是1,A在本地提交了2,3并且推送到远程了,B 进行修改的时候没有commit 操作,他先自己写了东西,然后 git pull 这个时候 B 本地版本已经到3了,B 在本地版本3的时候改了 A 写过的代码,再进行了git commit && git push 那么在远程版本中就是4,而且 A 的代码被覆盖了,所以说所有人都要先 commit 再 pull,不然真的会覆盖代码的

2.commit是提交到本地仓库，然后push，这个push是把所有代码推到远程仓库，还是只是把commit的地方推到远程仓库？

       肯定不会全量推送到远程的,是通过对比 commit 的记录,如果本地高于远程就直接把多出来的commit 给怼上去,如果本地的这几个 commit 和远程的 commit 有冲突的部分就merge,然后根据提交时间排序再新建一个merge 的 commit 记录再怼上去