在IDEA中使用Git！_idea git fetch

写在前面

工欲善其事必先利其器，在工作中我们写的代码大多数都是通过Git进行版本控制的。而面对复杂的git命令和不太友好的客户端，可能对于初学者是在不太友好，不管是命令还是git bash，都不太好操作。

IDEA作为开发神器，当然也是把git集成了进去，这篇文章就是针对IDEA使用Git作为讲解，就算是初学者也能明明白白学会。

点击获取IDEA

Git基本操作

首先我们入职一家公司，上司一般会给你一个Gitlab链接，让你拉代码，我们会用到git pull，然后熟悉之后在写代码会用到git add等等操作。

git add

当我们新建一个类或者文件时，IDEA一般会自动弹出如下提示，其作用和git add相同。

①

但如果你没有点击或者是跳过了，你可以看到新增的文件是红色的。

②

此时你可以右键选择git add操作，操作之后就会变成绿色

③

④

git commit

在add文件之后，我们需要提交文件。git和svn的区别就是，git提交是相当于把代码提交到本地仓库，并没有提交到远端分支上面去。

①

右键选择commit

②

填写提交记录，一般来说新功能以feat开头，修复bug以fix开头。

可以看到提交之后文件颜色变为黑色。

③

通过alt+9或者View打开git控制台，可以看到最新的提交记录。

git push

上面commit代码之后，我们需要把本地代码推送到远程分支上。

①

push之后我们可以去gitlab查看记录。

②

git pull

从远程获取最新版本并merge到本地。在主项目上面右键操作git pull。

①

或者是在上方，看个人喜好。

②

git fetch

从远程获取最新版本到本地，不会自动merge，并且拉取当前项目的所有分支的的提交。

①

在使用git fetch之后可以看到最新的其他人的提交记录，而且是2个master分支和feat_branch分支的提交记录，而我们本地的代码是没有变化的。

我们双击不同分支的提交记录，可以看到对应的差别。

②

git merge

上面说到，git fetch是不会merge的，需要我们自己合并。

①

②

选择对应的分支。

③

通过上面的操作，可以理解git pull，fetch，merge的关系。

git fetch是将远程主机的最新内容拉到本地，用户在检查了以后决定是否合并到工作本机分支中。

而git pull 则是将远程主机的最新内容拉下来后直接合并，即：git pull = git fetch + git merge，这样可能会产生冲突，需要手动解决，遇到冲突，解决冲突。

git rebase

rebase（变基），官方解释比较干燥，很么意思呢，简单来说就是用于把另一个分支的修改合并到当前分支。

dev分支是我基于master分支拉取的新的分支。

在这之前master分支有过4次提交记录，此时master和dev分支都在C4节点上。

然后我们在dev分支生成2个commit，master分支也生成2个commit，通过git控制台查看日志。

此时，2个分支处于分叉状态。

我们在master分支rebase dev分支

①

②

在rebase的过程中，可能会出现冲突， 在这种情况，Git会停止rebase并会让你去解决冲突，在解决完冲突后，在push到远端仓库。

③

④

此时我们在控制台也可以看到master分支变成了一条直线。

即

当然，在实际开发中rebase尽量的少用，因为会把别人的提交记录冲掉，如果到时候别人的代码有问题，但是最新的commit记录又是你的，你懂的。

git revert

在多人开发的过程中，我们有时会出现错误提交的情况，此时我们希望能撤销提交操作，让程序回到提交前的样子。

revert 用来回滚某个 commit，但是保留了前面或者后面的版本。比如我们commit了3个版本C1,C2,C3,

但后面发现版本C2有bug，想要撤销C2，但又不想影响撤销C3的提交，就可以用 git revert 命令来操作，同时生成新的版本C4，C4版本里会保留C3的提交，但撤销了C2的提交。

①

commit3次

②

在C2版本右键revert

③

合并C1,C3版本提交

④

日志记录

git reset

回退到某个版本的所有commit。如commit了3版本C1,C2,C3,如果需要回退到C1,可以使用reset。

reset的作用是修改HEAD的位置，即将HEAD指向的位置改变为之前存在的某个版本。

HEAD：使用git的每次提交，Git都会自动把它们串成一条时间线，这条时间线就是一个分支。如果没有新建分支，那么只有一条时间线，即只有一个分支，在Git里，这个分支叫主分支，即master分支。有一个HEAD指针指向当前分支（只有一个分支的情况下会指向master，而master是指向最新提交）。每个版本都会有自己的版本信息，如特有的版本号、版本名等。如下图，假设只有一个分支：

①

三次提交记录

②

③

④

代码变为C1版本，但这个时候远端仓库的代码并没有回退。

⑤

远端仓库，如果需要修改可再次push或者重新拉取分支即可。

常见的使用场景

上面讲了很多git操作，其实大部分同学都知道，但在不理想情况下，还是会出现很多问题，比如修改提交记录，多分支合并，代码冲突等等。

git rebase修改提交记录

假如在某次提交代码太快，还是用的上次的commit信息，或者是描述有问题，但是又commit了（只commit没有push）

①

此时看commit记录是不对的

②

③

通过rebase操作修改，选择对应的提交记录，点击Reword

④

修改后在点击 Start Rebasing

可以看到commit信息就修改过来了，此时再去push到远端仓库即可

⑤

上面的操作针对的是commit操作，并不是commit&push操作，也就是说修改的是本地的提交记录。

为什么会有这种情况？

现在很多公司都有代码检查，比如阿里的，或者是check-style，对应gitlab也是可以对commit信息做限制的，即commit信息未按照指定格式，你执行commit&push操作，只会commit到本地，而不会push到远端。比如我之前的公司commit信息的格式为：

bugid:xxx   或者   featid:xxx
1

上面的冒号规定是英文的，但我手速太快，写成了中文的冒号，此时就不能push上去，所以需要修改之后再次push即可。

⑥

当然，还有个最简单的办法，右键commit的记录，会直接弹出一个修改框。

⑦

修改点击ok即可

那就有人问了，那如果是代码检查不通过怎么办？我是需要修改代码再次commit的，那我同一个功能，就因为代码检查提交2次，日志看起来也比较冗余。看下面声明：本文内容由网友自发贡献，转载请注明出处：【wpsshop博客】