揭秘Git合并机制：为何先commit后pull再push，避免代码覆盖的真相

目录

问题 

理解Git的合并机制 

---

问题 

这两天网上冲浪时，发现有人提问这样一个问题：

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

 这位兄台对于pull有个误区，他认为pull会直接将远程仓库的代码覆盖到本地，实则不然。

首先，在多人协作的环境中，远程仓库是团队成员共享代码的地方。通过pull操作，你可以将远程仓库中的最新改动拉取到本地。在提交自己的改动之前，先拉取远程仓库的改动，可以及时发现并解决潜在的代码冲突。

其次，虽然pull的意思是“拉取”，但是pull并不会覆盖本地代码，我们来深入理解一下pull。

理解Git的合并机制 

当执行git pull命令时，Git实际上执行了两个步骤：

1. Fetch（获取）：从远程仓库获取最新的改动，但不将这些改动合并到你的当前分支。这一步类似于“预览”远程仓库的最新状态。

2. Merge（合并）（或Rebase，取决于您的配置）：将远程仓库的改动与你的本地改动合并。Git会尝试自动解决冲突，但如果存在冲突，它会暂停合并过程，让你手动解决。

 也就是说，pull是为了发现冲突并解决冲突，git 也会把这个冲突给标记出来,这个时候与和你冲突的那个人协商保留谁的代码,然后再 git add && git commit && git pull ,再次 pull 一次是为了防止在你们协商的时候另一个人给又提交了新的一版东西,如果是这样，那上面的流程就再重复一遍,通常没有冲突的时候就直接给你合并了,而并不会把你的代码给覆盖掉。