文章目录

* 结论 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 查看历史等等。

友情链接
ioDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信