常见的Git命令

Git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理，是Linus（Linux之父）为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。

本篇博客只介绍常用的命令，并不会全部介绍。并且由于我接触Git的时间并不长，有很多命令暂时还没有用到，以后遇到了再做补充。

说明：本人在刚开始写这篇博客的时候，GitHub账号名称为zhenyoung6。后面用了一段时间的Git后对于其又有了新的认识，遂对博客中的一些内容进行了修改，期间也将GitHub的账号名称修改为了zhenyoung，所以可能会出现账号名称不一致的情况，特此说明。

1. 初步认识Git

1.1 Git与SVN的主要区别（简要了解）

目前在众多的版本控制系统中，Git与SVN使用最为广泛。

SVN是集中式版本控制系统，版本库集中放在中央服务器上。

工作时，甲先从中央服务器获得最新的版本，然后工作（一般是写代码），完成工作后再把自己的代码推送到中央服务器。同事乙若想进行协同工作，则只能从服务器上再将代码获取到本地，修改完后再推送到服务器上。甲乙之间不能互相推送代码，在从服务器拉取代码前也就不知道对方做了那些修改。

集中式版本控制系统必须联网才能工作，对网络带宽的要求更高。

Git式分布式版本控制系统，没有中央服务器，每个人的电脑就是一个完整的版本库，工作的时候不要联网了，因为版本都在本地（自己电脑上）。

工作时，甲在PC上修改了代码，同事乙在PC上也修改了A，此时，两人之间只需要将自己的修改推送给对方，就可互相看到对方的修改了。

1.1 安装Git

• Windows
  在官网下载Git最新版本后，安装。然后在命令窗口输入以下命令：

git config --global user.name "Your Name" #Git用户名
git config --global user.email "email@example.com" #邮箱

注意git config命令的–global参数，用了这个参数，表示你这台PC上所有的Git仓库都会使用这个配置

#查看系统config
git config --system --list #-l也行

#查看当前用户（global）配置
git config --global --list #-l也行

• Mac OS X
  就是直接从AppStore安装Xcode，Xcode集成了Git，不过默认没有安装。需要运行Xcode，选择菜单“Xcode”->“Preferences”，在弹出窗口中找到“Downloads”，选择“Command Line Tools”，点“Install”就可以完成安装了
• Linux（Ubuntu）
  在终端中输入sudo apt-get install git即可完成安装

# 一些常用的shell命令
touch file.txt	# 在当前目录新建file.txt文件
rm file.txt 	# 删除该文件
rm -r src 		# 删除目录src，如果加上-f合成-rf就是强制删除了
mv srcfile.txt dir # 将srcFile.txt文件移动到dir目录下
cat srcFile.txt # 查看文件内容而不用在编辑器中打开该文件

1.2 创建版本库

版本库又名仓库（repository），可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。所以，创建一个版本库十分简单：

首先在一个合适的地方创建一个空目录，然后进入该目录，通过git init命令把这个目录变成Git可以管理的仓库：
当前目录下多了一个.git的目录（勾上隐藏的项目即可看到），这个目录是Git来跟踪管理版本库的，不要动它！！！不要动它！！！不要动它！！！

首先明确一下，所有的版本控制系统，都只能跟踪文本文件的改动，比如txt文件、网页、程序代码等等，Git也不例外。版本控制系统可以告知每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”等。

但是图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

在git1目录下新建一个readme.txt文件：

Nobody knows China better than me.
It's a fake news.
没人能在法国投降之前占领巴黎。

和把大象放到冰箱需要3步相比，把一个文件放到Git仓库只需要2步：

• 第一步：用命令git add把文件添加到仓库：

git add readme.txt # readme.txt代表工作区中的readme.txt文件

• 第二步：用命令git commit把文件提交到仓库：

git commit -m "first commit"
# m表示message，后面输入的是本次提交的说明，这样就能从历史记录里方便地找到改动记录
# 后面使用了标签后更方便，但是标签一般不要乱加，容易混乱

可以多次add不同的文件，最后一次性全部提交，比如：

git add file1.txt
git add file2.txt file3.txt
git commit -m "add 3 files."

# 一般为了省事，通常添加所有的文件修改
git add .

1.3 总结

初始化一个Git仓库，使用git init命令；

添加文件到Git仓库，分两步：

1.使用命令git add ，注意，可反复多次使用，添加多个文件。建议使用git add .；
2.使用命令git commit -m “message”，提交

2. Git工作原理

2.1 修改文件（演示，了解即可）

修改readme.txt文件，用命令git status查看结果：

上述输出结果告诉我们：readme.txt被修改过了，但还没有提交。若要查看修改的内容，则输入git diff readme.txt：

可以看到，改动是将句号去掉了。若再次修改，在上一次修改的基础上将前两句的句号也都删除：

可以发现，之前的修改并没有在保存到仓库中，原来的没人能在法国投降之前占领巴黎仍然是带有句号的。再修改一次，将首字母改为小写：

可以看到，之前的修改仍然没有保存。此时，将修改添加到仓库后再提交，然后查看仓库状态时，发现Git告诉我们当前没有需要提交的修改，而且工作目录干净（working tree clean）

• 总结
  1.要随时掌握工作区的状态，使用git status命令；
  2.如果git status告诉你有文件被修改过，用git diff可以查看修改内容

2.2 版本回退（演示，了解即可）

首先，用git log命令查看提交（commit）的历史记录：

我们可以看到有2次提交，其中first commit和second commit是提交时加上的说明message，当前仓库所处的状态是第2次提交之后的状态，若觉得容易眼花缭乱，可以加上–pretty=oneline参数：

在Git中，HEAD表示当前版本，上一个版本是HEAD^{，上上个版本是HEAD，上上上个版本是HEAD}^^，依此类推。
若要将当前版本（second commit）回退到上一个版本（first commit），输入：

git reset --hard # 重置暂存区与工作区

结果显示当前版本的版本号commit id与第1次提交时的版本号一致，说明回退到了上一个版本：

再次查看仓库的状态时发现second commit版本已经消失不见了 。若又想回到最新的版本second commit，则需要输入：

git reset --hard 8e381 # 版本号写前几位即可，Git会自己去找。当然了，也不能只写前一两位

此时查看readme.txt的内容：

可以看到，成功回退到了second commit版本。而且回退速度非常快，因为Git内部有个指向当前版本的HEAD指针。回退版本的时候，Git仅仅是将HEAD指针由指向first commit改为指向second commit，然后顺便把工作区的文件更新了，所以HEAD指向哪个版本，当前版本就定位在哪。

如果不记得了id号，可以用命令git reflog查看命令历史（记录每一次HEAD的改变）：

• 总结
  1.HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id；
  2.穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本；
  3.要重返未来，用git reflog查看改变HEAD的命令历史，以便确定要回到未来的哪个版本

2.3 Git的区域（重点）

• 工作区（Workspace）
  放项目代码的目录

• 本地版本库/仓库（Local Repository）
  工作区有一个隐藏目录.git，这个就是Git的版本库。版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区。还有Git为我们自动创建的第一个分支master（也叫主分支），以及指向master的一个指针HEAD。

git add把文件添加进版本库，实际上就是把文件修改添加到暂存区。git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支

因为创建Git版本库时，Git自动为我们创建了唯一的master分支，所以现在git commit就是往master分支上提交更改。可以简单理解为：需要提交的文件及修改都放到暂存区，然后，一次性提交暂存区的所有修改

• 远程仓库（Remote Repository），第三章再谈
  下面给出一个例子：在git1目录下新建一个LICENSE文件，内容随便写，修改readme.txt文件，然后查看暂存区状态：
  
  Git非常清楚地说明了：readme.txt被修改了，而LICENSE还从来没有被添加过，所以它的状态是Untracked。现在，把readme.txt和LICENSE都添加后，再查看一下状态：
  
  此时的状态如下所示：
  
  一旦提交后，如果又没有对工作区做任何修改，那么工作区就是“干净”的：
  
  现在版本库中暂存区就没有任何内容了，状态如下：
  

2.4 管理修改（演示，了解即可）

Git追踪的并不是文件，而是修改，下面举一个例子说明。

在文件末尾增加一行年轻人不讲武德。，然后add，然后删掉句号，然后提交，查看状态：

可以看到，第2次的修改即删除句号的修改并没有被添加，自然也就不会被提交了。

整理一下过程：第1次修改 -> git add -> 第2次修改 -> git commit

其实，Git管理的是修改，当用git add命令后，工作区的第1次修改被放入暂存区，准备提交，但是工作区的第2次修改并没有放入暂存区。所以git commit只负责把暂存区的修改（即第1次的修改）提交了，第2次的修改由于没有添加进暂存区，不会被提交。

输入：

git diff HEAD -- readme.txt # HEAD代表当前分支，而当前分支又是指向最新提交的，也就是最新版本库
# readme.txt代表工作区中的文件

查看工作区（绿字） 与版本库中的最新版本（红字）之间的区别：

可见，第2次修改确实没有被提交。若想提交第2次修改，则只需将其添加，然后再提交即可：

可以看到，添加再提交后，工作区与版本库之间没有区别，所以用git diff HEAD – readme.txt命令时没有显示，而且暂存区是空的。

• 总结
  每次修改文件，如果git add添加到暂存区，那么就不会加入到commit中

2.5 撤销修改（演示，了解即可）

1.假设此时工作区中改乱了文件的内容（此处的修改就是加上了末尾的一句话），此时还未add：

若想直接丢弃工作区的修改，输入：

git checkout -- readme.txt # readme.txt代表工作区的文件

可以看到，该文件的修改被撤销掉了。

实际上，git checkout – readme.txt把readme.txt文件在工作区的修改全部撤销有两种情况：

• readme.txt修改后没有添加到暂存区，此时，撤销修改就回到和版本库一模一样的状态；
• readme.txt添加到了暂存区，然后工作区的文件做了修改，此时，撤销修改就回到添加到暂存区后的状态；

总之，git checkout – readme.txt将使这个文件回退到上一次git commit或git add时的状态

2.假设此时工作区改乱了文件的内容（此处的修改就是加上了末尾的一句话），而且已经add到暂存区中了：

若想撤销本次修改，输入：

git reset HEAD readme.txt
# reset既可以回退版本，也可以撤销add操作

把add到暂存区这个操作给撤销掉（unstage），重新放回工作区，然后重复前面的步骤，即输入：

git checkout -- readme.txt

可以看到，该文件的修改被撤销掉了。

3.至于已经提交到版本库的撤销操作，只能通过版本回退来修改版本（不过前提是没有推送到远程库）

• 总结
  1.场景1：当改乱工作区某个文件的内容，但没有添加到暂存区时，想要撤销修改，用命令git chekout – file
  2.场景2：当不但改乱了工作区某个文件的内容，而且添加到了暂存区时，想要撤销修改，分两步：第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作；
  3.场景3：已经将修改提交到版本库时，想要撤销本次提交，只能通过版本回退来修改版本（不过前提是没有推送到远程库）

2.6 文件删除（演示，了解即可）

首先，新建一个文本文件test.txt，内容随意，提交。然后输入：

rm test.txt # 或者在电脑上delete删除

删除该文件。此时Git知道该文件已经删除了，故而工作区（已经删除了）和版本库（还未删除）就不一致了，此时通过git status查看状态：

现在有两个选择：

• 从版本库中删除该文件，则输入：

git rm test.txt # git add再将此时的工作区添加也是一样的效果

然后提交，这样文件从版本库中删除了。

注意：一开始如果直接用git rm test.txt删除文件，那么该文件是无法恢复的，因为git rm命令是直接从版本库中删除文件。

• 从版本库中恢复文件到工作区中，则输入：

git checkout -- test.txt
# 上一节提到，这条命令将使这个文件回退到上一次提交或添加时的状态
# 无论工作区是修改还是删除，本质上都是撤销回到上一步：
# 1.没有add到暂存区，修改，执行撤销操作使工作区回到上一步，也就是回到版本库
# 2.add到暂存区，然后修改，执行撤销操作使工作区回到上一步，也就是回到暂存区
# 3.没有add到暂存区删除文件，执行撤销操作使工作区回到上一步，也就是回到版本库
# 3.add到暂存区后删除文件，执行撤销操作回使工作区到上一步，也就是回到暂存区
# 情况还有很多，就不一一列举了

注意：没有被添加到版本库的文件，删除之后是无法恢复的！换言之，添加后的文件删除（非git rm）之后是可以恢复的

3. 远程仓库Remote Repository（重点）

3.1 关联主机与GitHub（重点）

这个世界上有个叫GitHub神奇的网站（也被称作“世界最大同性交友网站”），从名字就可以看出，这个网站就是提供Git仓库托管服务的。所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库。由于Git仓库与GitHub仓库之间的传输是通过SSH加密的，所以需要进行一些设置：

1.创建SSH Key。在用户主目录下（我这里是C:\Users\29239），看看有没有.ssh目录：

如果有，再看看有没有id_rsa和id_rsa.pub这两个文件，如果有，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），输入如下命令创建SSH Key：

ssh-keygen -t rsa -C "youremail@example.com"

输入邮箱后，直接一路回车。如果一切顺利，可以在用户主目录里找到.ssh目录。里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人

2.登录GitHub，打开“Account settings”，“SSH Keys”页面。然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴公钥（id_rsa.pub文件的内容），点“Add Key”，就可以看到已经添加的Key：

当然，GitHub允许添加多个Key。如果有多台电脑，一会儿在公司提交，一会儿在家里提交，那么只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。

3.2 添加远程仓库（重点）

首先，登录GitHub，然后点击左上角repository的new按钮，创建一个新的仓库。然后在Repository name填入git1，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库：

目前，GitHub上的这个git1仓库还是空的。现在，在本地的git1仓库下输入：

git remote add origin git@github.com:zhenyoung6/git1.git

将本地git1仓库与远程仓库git1进行关联 ，其中，origin就是远程库的名字，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库，所以如果不是强迫症，就用origin这个名字

下一步，把本地库的master分支推送到远程库上的master分支：

git push -u origin master

推送成功后，可以在GitHub页面中看到远程库的内容已经和本地一模一样：

由于远程库是空的，所以第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送到远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令：

git push # 默认本地master分支推送到远端mster分支

# 如果是其他分支比如branch1，就必须切换到branch1分支，然后推送
# 跨分支推送是无效的，比如：分支branch1是不能推送到master分支的
# 本分支做好本分支的事

# 推送所有的分支到远程
git push origin --all

把本地master分支的最新修改推送到GitHub。正因为是将master分支推送到远端，所以在修改后一定要将暂存区的修改内容提交到master分支

3.3 从远程仓库拉取（重点）

# 取回远程仓库的变化，并与本地分支合并
git pull origin master
# 由于有合并操作，所以千万不要跨分支拉取！！！千万不要跨分支拉取！！！千万不要跨分支拉取！！！（详见4.2）
# 即：当前分支要与拉取的分支一致，master分支拉取master分支，dev分支拉取dev分支

3.4 从远程仓库克隆（重点）

# 克隆一个项目和它的整个代码历史（版本信息）
git clone url

# 或者使用ssh克隆
git clone ssh
# ssh的格式为 git@github.com:用户名/仓库名.git
# 如果是国内的Gitee码云，则是 git@gitee.com:用户名/仓库名.git

有个细节，上面的命令会将远端的仓库克隆到本地当前路径下，并且克隆下来的是工作区（以仓库名命名的文件夹）。如下所示：

但是如果后面加上目录的话，情况会有所不同：

# 将仓库工作区内的所有文件及目录克隆到当前路径下的test1目录下
git clone git@github.com:zhenyoung/JavaBooks.git test1/
# 如果当前路径下test1目录不存在，则会先创建test1目录，然后再克隆到test1目录下

如下所示：

我一般懒得记这些东西，直接克隆。实在不行的话就切换到目标目录下，然后再克隆嘛

• 总结
  1.要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆
  2.Git支持多种协议，包括https，但ssh协议速度最快，而且免密码，所以推荐使用ssh

4. 分支管理（重点）

所谓分支，通俗地可以理解为不同的版本，仓库中的不同分支相互之间不会产生任何关联。

举个例子，流水线上的工人，每个人都是不同的分支：插电阻的是一个分支，插CMOS管的是一个分支，插晶振的是一个分支，彼此之间没有任何关联，你插你的器件，我插我的器件。

再比如，一个App的开发，它可能有多个版本v1.0、v2.0、v3.0…。从程序代码的角度讲，不同的版本之间由于兼容性以及业务逻辑的问题，确实会有很多程序是一样的（甚至可能v2.0就仅仅比v1.0多了个背景音乐）。但是为了方便管理，一般就会把不同的版本之间放到不同的分支之中，比如v1.0相关的程序代码放到名为1.0的分支中，v2.0放到名为2.0的分支中。

当前分支：HEAD指向的分支就是当前分支。需要注意的是：文本编辑器打开文的件是当前分支提交的文件

分支常用命令（本章主要讲的就是这些命令）：

# 列出所有本地分支
git branch
# 列出所有远程分支
git branch -r

# 新建一个分支，但HEAD仍然指向当前分支
git branch branchName
# 切换到新的分支（切换分支其实就是将HEAD指向该新分支）
git switch branchName 
# 了解一下：以前的版本会使用 git checkout branchName 切换分支，但是现在推荐使用见名知意的switch切换
# 新建一个分支，同时将HEAD指向该分支
git switch -c branchName # c代表create
# 了解一下：以前的版本会使用 git checkout -b branchName 创建并切换分支（b代表branch），但是现在还是推荐使用见名知意的switch

# 合并指定分支到当前分支
git merge branchName

# 删除分支
git branch -d branchName
# 删除远程分支
git branch -dr zhenyoung/branName # 这里使用的是我的GitHub远端用户名

4.1 创建、合并、删除分支（重点）

HEAD指向当前分支，当前分支指向最新的 commit提交。这里由于只有master分支，所以HEAD指向的当前分支就是master。比如下图中括号里的master就是HEAD指向的当前分支：

每提交一次，master就向前移动一步指向该提交。这样，随着不断提交，master分支的时间线也越来越长。

首先创建dev分支，然后切换到dev分支：

git switch -c dev
# c代表create，上述命令相当于执行了以下两条命令：
git branch dev
git switch dev

查看当前分支：

然后，就可以在dev分支上正常提交，比如在readme.txt加上一行：

Creating a new branch is quick.

然后提交，之后切换回master分支：

git switch master

切换回master分支后，再查看readme.txt文件时，发现刚才添加并没有出现。这是因为那个提交是在dev分支上完成的，而master分支指向的提交并没像dev的提交那样作出了修改：

现在，将dev分支的提交合并到当前分支master上：

git merge dev

可以看到，合并后dev分支的最新提交的内容是完全一样的：

合并完成后，删除dev分支：

git branch -d dev

4.2 冲突（重点）

下面举一个例子说明冲突的问题：

首先创建分支并切换：git switch -c feature1，然后修改readme.txt最后一行，改为：

Crreating a new branch is quick AND simple.

在feature1分支上提交，然后切换到master分支：

Your branch is ahead of ‘origin/master’ by 1 commit.提示我们：当前master分支比远程的master分支要超前1个提交。在master分支上把readme.txt文件的最后一行改为：

Creating a new branch is quick & simple.

然后在master分支上提交：

这样，master分支和feature1分支的提交都对readme.txt文件进行了修改，变成了这样：

此时在master分支执行合并操作：

git merge feature1

可以发现：合并出现冲突且冲突出现在readme.txt文件中，必须解决冲突后提交：

git status也说明了冲突是因为两个分支都对同一个文件进行了修改，此时不能将两个分支合并：

此时查看readme.txt的内容：

其中的<<<<<<<，=，>>>>>>>标记出了不同分支之间对该文件的改动。

由上也可以看到，分支也不能一股脑合并，如果两个分支都对同一个文件进行了修改，那么在分支合并时就不知道是谁合并谁了，从而会引起冲突导致合并失败。
这里并不会介绍如何修复冲突，因为一方面没有任何意义，另一方面这样很容易养成在分支上乱改文件的坏习惯，这里只介绍如何避免这种问题。为了避免上面的问题，下面是大家默认遵守的规则：

预先新建一个分支用来发布新版本比如v1.0，那么关于v1.0版本的开发工作（写代码）则在另一个分支比如dev分支上完成。

当最终的项目代码确定下来后准备发布时，把dev分支的工作合并到master分支，然后在master分支上发布v1.0（将master分支合并到v1.0分支即可）。

换句话说，master分支就是用来发布新版本的，一般不在上面工作，所以千万不要跨分支修改文件！！！

虽然不遵守上面的规则也不会怎么样，但是既然这样做可以避免冲突问题，那又何必自己给自己找麻烦呢？一天到晚想着创新，想着所谓“个性化”，乱建分支，你倒是看得懂自己，你同事呢？这种行为不是创新，是蠢！！！

5. 标签（重点）

每次的commit提交都会有一个id号以代表该次提交，但是id号不便记忆，所以经常给它打上标签。标签一般用来作为应用发布时的版本号，比如v1.0 Release、v1.0、1.0等，所以就会将发布前的最后一次提交打上标签。其他的标签一般没什么意义，所以也建议不要随意乱打标签（标签多了容易混乱，难以管理）。
常用的标签命令如下：

git show # 显示当前分支下的所有标签信息
git show v1.0 # 显示标签为 v1.0 的提交信息

git tag # 查看当仓库下的全部标签
git tag v1.0 # 默认给当前分支的最新提交贴上标签 v1.0 
git tag v1.1 5c03c59 # 给仓库下id号为5c03c59的提交贴上标签 v1.1，如果不知道提交的id号，git log查询

git push origin v1.0 # 推送标签 v1.0 
git push origin --tags # 推送仓库的全部标签

git tag -d v0.1 # 删除本地标签 v1.0
# 删除远程标签 v1.0，共需2步：
git tag -d v1.0
git push origin :refs/tags/v1.0

注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签（或者说给两个分支的提交打上了相同标签）。

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除git tag -d v0.9。然后，从远程删除git push origin :refs/tags/v0.9：

6. IDEA中使用Git

实际开发中，往往会不断地进行Git的相关操作，但是需要在shell和IDE之间来回切换进行修改和提交，为了迎合人类“懒”这一特点，IDE中往往都会集成Git，所以学会在IDE中使用Git十分重要，这里以IDEA为例。

以前的版本需要手动add添加，我现在的IDEA版本是2021.1，不需要手动add添加，所有的修改都会自动添加到暂存区。
其中，绿色标定的就是增加的部分，蓝色标定的是修改的部分，如果修改行的增加行是连续相邻的行，则会统一成蓝色（默认的设置是这样的，可以自定义）。

修改完代码后，直接提交修改就行了：

右上角的两个图标，蓝色的箭头表示将远程仓库拉取到本地，绿色的勾代表提交，

弹出的提交框中，也可推送到远端，所以我更喜欢上面蓝色和绿色的两个按钮，虽然右边的绿色箭头代表push，但是我如果没有提交push就没有意义了。所以既然打开了commit，索性就在这里提交和推送了。

如果要是更懒，就可以在IDEA中的terminal中输命令，然后下一次提交推送修改的时候，直接按一下↑就能直接复制上一次的命令（这是命令行的通用功能），免去了输入的麻烦（虽然也就几个单词，但是架不住不断地提交修改啊，那也是很累的）

更多的IDEA中的Git操作（非终端的）多用用就会了，这里就不做赘述了。

7. 忽略文件gitignore

有时候我们并不希望某些文件纳入版本控制中（追踪它的修改没有意义），比如Java项目下的.idea、.gradle文件夹下的文件，再比如一些日志文件、临时文件、编译产生的中间文件等。

为此，在主目录下（workspace目录下）新建gitignore文件，在文件添加不需要纳入版本控制的文件，书写规则如下：

1.可以使用Linux通配符，例如：星号*表示多个任意字符，问号?代表一个字符，方括号[a-d]代表可选字符范围，大括号{string1,string2,…}代表可选的字符串等；

2.如果名称前面有一个感叹号!，代表例外规则，将不被忽略；

3.如果名称最前面是一个路径分隔符/，表示只忽略根目录下的文件，而其子目录中的文件不忽略；

4.如果名称最后面是一个路径分隔符/，表示忽略此目录及目录下的所有文件和子目录

#井号注释，下面只举一些例子，很多并没有提到
*.txt		# .txt结尾的文件将会被忽略
!lib.txt	# 上述结尾文件中lib.txt文件除外
/temp		# 仅忽略根目录下的temp文件，其子目录不忽略
build/		# 忽略build目录及目录下的所有文件和子目录
doc/*.txt	# 忽略doc目录下的所有txt文件