push操作前，git commit与git pull（fetch+merge）的先后顺序问题详解

1、流程对比

pull->commit->push #在本地修改与远程代码无冲突的情况下，优先使用
commit->pull->push #在本地修改与远程代码有冲突的情况下，优先使用

2、怎么去确定是否有冲突呢？

一般我们在合作开发一个项目的过程中，都会有分工

• 有时会两个人同时修改一个类，那你俩就大概率会在这个类里面产生冲突;
• 有时整个类都是你自己在开发。如果都是自己在开发的类自然无论如何都没有冲突，但也有特殊情况，比如你在test分支上修改了User.java然后push到远程仓库，然后你在master分支合并了test分支去灰度环境进行测试，测试发现有个小bug，但你们公司不允许你直接动master分支，你只能跑到test分把这个小bug改完，再用master分支合并这个test分支，这样在User.java上就会出现冲突,同理，你自己的分支dev-wzh，没有动过a.java文件，但如果用master分支分别dev-wzh的时候，如果别人动过master，那么也会出现冲突

3、如果有冲突的情况下，先pull了会出现什么问题呢？
如果你的判断失误，在本地修改与远程代码有冲突的情况下，先执行了git-pull，即使是这样也不用担心，git会给你一个错误提示，这时候你再去执行commit->pull->push也是没有问题的。如下

你需要先commit，然后再pull，使用idea时，先commit，再pull，如果有冲突，会弹出让你合代码的窗口（不是提示语，是一个分为三块的代码窗口，左边自己的代码，中间是待合并代码，右边是远程代码，将正确的代码往中间合的这么一个窗口）吗 我平常是直接pull，然后有冲突就会弹出上述窗口，可以一目了然的去解决冲突，然后就commit and push，就完成了

4、没有冲突的情况下，先commit再pull有什么影响呢？
本质上是没有影响的，如果按照pull => commit => push的流程，呈现出来的就会是一条没有merge、没有多余commit的一条完美分支，如果按照commit => pull => push

比如我们本地test分支落后远程test分支3个版本，再次基础上我们本地分支提交一个新版本d，然后在pull的过程中，pull的流程是先fetch，fetch下test分支上领先的三分版本a,b,c其中a是fetch下来的最新的版本，然后此时本地的HEAD是执向d的，然后执行merge，远程分支和本地分支相互合并，这里本质上是合并a和d;其中这里还会展示a和d的修改信息

没有冲突顺利合并，有冲突需要手动解决然后再提交一次来解决冲突，完成合并，如果有冲突的话肯定是要解决的，这点无可厚非，但如果没有冲突的话，这种merge就显得有些多余了，如下图所示

有问题的会话：

先pull再commit的话, 你的commit也就不再纯粹了. 这一个commit不再是"你所编辑的xxx功能, 而是"别人所编辑的+你所编辑的xxx". 我认为提交历史最主要的功能在于历史清晰. 只要能让人更好的看清每个commit的内容, 再多几个merge点又如何?我个人更推荐先commit再pull, 还推荐更小粒度的commit, 频繁的commit.

提交代码的时候先更新再提交，robot-statistics项目不能引入wb-util项目