通过idea提交代码引申出 "关于git应该先pull，还是应该先commit"、"为什么idea提交的时候没有git add操作" - 好文

文章目录

* 结论 1 ：关于git应该先pull，还是应该先commit
<https://blog.csdn.net/dataiyangu/article/details/91050707#_1__gitpullcommit_1>
* 问题 1 ：关于git应该先pull，还是应该先commit
<https://blog.csdn.net/dataiyangu/article/details/91050707#_1__gitpullcommit_3>
* 剖析 1 ：关于git应该先pull，还是应该先commit
<https://blog.csdn.net/dataiyangu/article/details/91050707#_1__gitpullcommit_8>
* 结论 2 ：为什么idea提交的时候没有git add操作
<https://blog.csdn.net/dataiyangu/article/details/91050707#_2___ideagit_add_39>
* 问题 2 ：为什么idea提交的时候没有git add操作
<https://blog.csdn.net/dataiyangu/article/details/91050707#_2___ideagit_add_43>
* 剖析 2 ：为什么idea提交的时候没有git add操作
<https://blog.csdn.net/dataiyangu/article/details/91050707#_2___ideagit_add_45>

<>结论 1 ：关于git应该先pull，还是应该先commit

git pull 和 git commit 没有绝对的谁先谁后，但是你要注意 git pull 到 git push 这段时间你的协同者有没有新的提交
，所以git commit -- git pull 是合理的，idea 中 git pull -- git commit 也是合理的

<>问题 1 ：关于git应该先pull，还是应该先commit

前年在一家公司的时候习惯用idea提交代码，pull – commit --push，到了现在这家公司一直用命令行提交，一年内一直是commit –
pull – push ，最近想着用idea提交，突然发现了这个问题：

到底是应该先pull呢，还是应该先commit呢？

<>剖析 1 ：关于git应该先pull，还是应该先commit

先引用两张图，图片出处（这两个里面也有关于git pull 和 git commit 的讲解，感谢）：
https://www.cnblogs.com/wnbahmbb/p/6568179.html
<https://www.cnblogs.com/wnbahmbb/p/6568179.html> ，
https://www.cnblogs.com/songshu120/p/5125000.html
<https://www.cnblogs.com/songshu120/p/5125000.html>

众所周知 git pull = git fetch + git merge
通过上图也能看到
git fetch 是将远程的代码拉取到了本地仓库的位置，也就是本地代码commit之后的地方
git merge 是在工作区进行的
也不难看出 git pull是将代码从远程代码直接拉取到了工作区，也可以理解为idea的编辑代码的地方。

所以，如果第一次pull和第二次pull之间本地没有对代码进行修改的话，不管你commit了还是没有，如果工作区，即编辑代码的地方我们是没有动的，这样的话pull的结果都是一样的，因为从
本质上将都是为了将本地工作区的代码和远端的代码进行比较，而commit这个操作对工作区是没有任何影响的，所以不管你commit还是没有结果是一样的。

就像下图

只要工作区的代码和远端的代码没有区别，git pull操作，永远都返回Already up to date，管你commit 了还是没有。

但是如上图，在第一次pull 和第二次pull 之间，即 t1 和 t2
中的任意时间，远端的代码，你同事push了新的代码，这个时候，第一次pull一定是Already up to
date，但是第二次pull你就需要去解决冲突了，这个并不是去跟commit到本地仓库的代码比较，而是和工作区的代码进行比较的，
所以即使中间没有commit这个操作，第一次pull和第二次pull这段时间之内，即 t1 和 t2 之间有同事push代码，还是会出现冲突的。

再者，有没有发现 commit – pull – push 这个过程，pull的时候有冲突的话，需要解决冲突，然后 git add . – git
commit -m “” – git pull – git push ，所以这个完整的过程其实是commit – pull – 解决冲突 – git add
. – git commit -m “” – git pull – git push ，其实去掉前面的commit ，发现 pull – 解决冲突 – git
add . – git commit -m “” ，所以不管谁在前谁在后，本质上是一样的。

但是注意：不论怎样，push之前是一定要pull的，因为要保证和远端的代码同步，否则会覆盖掉别人的提交。

当然不仅是我自己的查阅资料加推理，也问了周围的同事，有工作十年的，有前后端的，ios的，他们有的是pull – commit
--push，有的是commit – pull – push ，工作这么久也没有出现问题。

综上所述：git pull 和 git commit 没有绝对的谁先谁后，但是你要注意 git pull 到 git push
这段时间你的协同者有没有新的提交，所以git commit -- git pull 是合理的，idea 中 git pull -- git commit
也是合理的

<>结论 2 ：为什么idea提交的时候没有git add操作
idea“背地里”帮我们偷偷的完成了git add 的操作
<>问题 2 ：为什么idea提交的时候没有git add操作

用idea提交代码发现 git pull – git commit --git push ，先抛开上面的git pull 的问题，正常的提交代码不应该是
git add . – git commit – git push 的吗？ git add 呢？被idea吃掉了吗？

<>剖析 2 ：为什么idea提交的时候没有git add操作

期初认为idea 集成 git commit 的时候默认是走的 git commit -am “”
的命令，这个命令的意思是，如果已经将文件加入了版本控制，之后只是进行修改的话，可以跳过git add 的操作直接 git commit。

在idea的version control 工具栏里面的 console 下是能看到idea“替”我们执行的git操作的。

综上所述：也就是说虽然我们只进行了git pull -- git commit ，但是idea“背地里”帮我们偷偷的完成了git add 的操作

当然了idea还是很强大的嘛，还能通过旁边的git log 查看历史等等。

热门工具换一换