在提出问题之前需要理解一下 pull 的底层原理，可以参考这篇博客：
详解git pull和git fetch的区别
然后提出几个在学习时的疑问，以及自己的理解（有些情况我没有实践，如有理解错误麻烦大牛指出）：
- 如果从远程仓库 pull 到本地仓库的话，会不会覆盖工作区？
答：工作区是会被覆盖的，所以在 pull 之前需要将未完成的工作存到 stash 中，避免被覆盖。不过一般情况都是需要 push 的时候才会 pull，在 push 之前显然都会 commit ，所以这种情况发生的概率不大。 - 为什么 pull 之后再 push 就不会出现冲突了？
答：首先需要知道，git 是对 commit 敏感的，而不是对内容敏感的。pull 的本质是将远程仓库的内容合并到本地仓库中去，如果出现冲突需要人工解决冲突。那么在合并完成后，此时的 commit 一定是最新的，直接 push 到远程仓库就可以了。
看下图：
就比如现在远程仓库中有一个 dev1.0 分支，而你的本地仓库是 dev2.0 分支，现在你想要将 dev2.0 分支 push 到远程仓库中去，但是出现了冲突。所以你将 dev1.0 pull 到了本地仓库，并解决了冲突，最后生成了 dev3.0，此时再向远程仓库 push dev3.0，远程仓库就可以正常接收了。
用远程仓库的视角来理解一下就是： 对于 dev1.0 和 dev2.0，我不知道他们之间的关系，我只知道他们有冲突，所以push失败。但是我知道 dev3.0 是 dev2.0 的一个后继，说明 dev3.0 比 dev2.0 的版本更新，所以可以替换。
3. 如果 pull 之后，后悔了怎么办？
答：因为 pull 操作实质上也是一种 commit，所以直接用 reset 回溯就可以了
4.接3，回溯时报错 git Unstaged changes after reset 怎么办？
答：参考 git Unstaged changes after reset
小结：
在多人协作，本地仓库向远程仓库同步时，需要遵循先 commit，然后 pull，最后再 push 的流程，养成一个好习惯
