为什么要先commit，然后pull，最后再push？而不是commit然后直接push？

Question

实在想不明白，网上也没有讲这个的明确说法。
情况是这样的，现在远程有一个仓库，分支就一个，是master。然后我本地的仓库是从远程的master上clone下来的。大家都是clone下来，再在自己本地改好，再commit然后pull然后push，大家都是这么做的。那么现在问题来了：

1，那我本地这个也算是个分支？还是就是一个本地仓库？

2，如果我在远程新建了个分支，然后我pull了下来，那我本地到底有分支这个说法吗？我本地的分支是不是就是那个远程新建的分支？

3，本地仓库和本地分支有什么区别？

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

5，那为什么要先commit，然后pull，然后再push，我pull了，岂不是把自己改的代码都给覆盖掉了嘛，因为远程没有我改的代码，我pull，岂不是覆盖了我本地的改动好的地方了？那我还怎么push？

6，两个分支，A和B，A合并B和B合并A，有区别吗？

Answer 1

1. 本地和远程的关系相当于两个分支,你感觉一样是因为你git pull 的时候已经自动给绑定好对应关系了, set-upstream..balbala

2. 你远程新建了一个分支拉到本地的道理是一样的,属于复制了一份,但是本地分支和远程分支已经是两个东西了

3. 本地分支属于本地仓库里,是包含关系,一个仓库里可以有很多分支, 如果是 tag 的话可以分离出独立的仓库

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

5. 这个先 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,不然真的会覆盖代码的

6. 两个互相合并的唯一区别就是 A->B 的时候 B 分支上会产生一个 merge_commit 的信息,这个时候 B 是合并状态而 A 未合并状态,如果现在没有发生任何改动执行 B->A 就直接切换过去了,连 merge_commit 都不会生成了

这是我的博客有写的一些我平时 git 排错的步骤

Answer 2

见解

1.本地算一个clone体。

2.是得,如果远程有一个分支 dev，那么pull origin dev，本地就会有一个dev分支。

3.仓库是整个项目，分支算其中一个生产线。就和阿里巴巴集团不是只有一个淘宝一样

4.push会进行分析，当然不是所有，你可以自己测试，弄一些大文件，第一次新建项目的push会很慢，如果你加一个几k的文本，那这次传输很快

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

回答完毕，么么哒

Answer 3

1. 首先pull不会把你本地代码覆盖掉，而是提醒merge冲突，需要你手动merge一下；

2. 为什么要pull？因为对你来说你本地可能有个分支，你在这个分支上面工作，那么也有可能存在其他人和你一样的做法，也许你们的代码有依赖又或是有冲突，你肯定不能在master里面测试，你要确保自己分支是最新代码；

3. 本地分支代码不一定和本地仓库是一致的，你把本地代码提交了才会存到本地仓库中，就相当于本地分支是你开发的一个平台，但是最后开发的产出存放地址是本地仓库

两种都可以，只不过大部分人选择先pull，因为你没提交你的代码，别人提交了，这时候git会自动merge，而如果你提交了，有时候git自动merge会报冲突，选择先pull就是图一个方便和省事，当然也有人选择先push在pull，这样可以了解其他伙伴对代码的改动

通俗的说就比如原来master的代码快照是1，你的同伴改了提交了是2，你的提交代码是3，如果你先pull，那么就是3和1merge，而3包含1，git选择最新代码3覆盖1，不存在冲突关系，而你先push在pull，那就是2和3merge，这是git自动merge就会出错，因为他不知道哪些需要哪些不需要

merge问题
a和b合并 和 b和a合并 最后产生的代码是一样的，都是把两个分支需要的代码保留，集成一个大家都认可的代码

唯一不同的可能merge过程有点不一样，这个得视情况而定，不过大致上都差不多

Answer 4

中间多了一步pull有两个目的，第一是为了更新本地代码；第二是便于在本地合并冲突。如果中间没有pull这一步，直接push，有了冲突还是得pull来解决冲突。

Answer 5

没有中间的这一步 pull 也没有任何问题，这不是强制要求，不做也不会导致 git 出 bug。之所以建议在每次 push 之前习惯性地做一个 pull 操作，是因为这样可以减少远端接受你的合并请求的时候出现冲突的概率（push 之前的 pull 操作只是在本地提前解决可能出现的冲突，从而降低远端仓库合并时出现冲突概率，不是绝对消除远端合并冲突），更利于整个团队 git 流程的流畅运行。