【工作必备Git技能】一文彻底学会git命令

命令汇总（具体解释见下文）

命令格式	含义
git init	初始化Git仓库
git add <file>	添加文件到仓库
git commit -m <message>	提交到仓库
git status	查看仓库当前状态
git diff <file>	查看当前文件修改内容
git log	查看历史记录
git log --pretty=oneline	查看历史主要记录信息
git reset --hard HEAD^	回退到上一个版本
git reset --hard commit_id	回退到指定版本号
git reflog	查看命令历史
git checkout -- file	撤销工作区修改
git reset HEAD <file>	撤销暂存区修改
git rm test.txt	从版本库中删除文件
git push -u origin master	本地库推送到远程库（第一次需加上-u）
git remote add origin git@server-name:path/repo-name.git	关联一个远程库
git remote -v	查看远程库信息
git remote rm origin	删除远程库
git clone ******	从远程库克隆
git branch	查看分支
git branch <name>	创建分支
git checkout <name>	切换分支
git switch <name>	切换分支
git checkout -b <name>	创建&切换分支
git switch -c <name>	创建&切换分支
git merge <name>	合并某分支到当前分支
git branch -d <name>	删除分支
git log --graph --pretty=oneline --abbrev-commit	查看分支合并情况
git merge --no-ff -m "merge with no-ff" dev	加上--no-ff参数就可以用普通模式合并
git remote -v	查看远程库信息
git push origin branch-name	从本地推送分支
git checkout -b branch-name origin/branch-name	在本地创建和远程分支对应的分支
git branch --set-upstream branch-name origin/branch-name	建立本地分支和远程分支的关联
git pull	从远程抓取分支
git rebase	把本地未push的分叉提交历史整理成直线

Git安装（linux下）

• 先从Git官网下载源码（下载地址）
• 使用传输工具到linux上，然后解压

$ tar -zxvf git-2.22.0.tar.gz

• 依次输入：

$ ./config
$ make
$ sudo make install

• 查看版本

$ git --version

创建版本库

相当于将当前文件使用git管理。

• 第一步创建文件夹（比如说learngit目录）

$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit

• 第二步：通过git init 将该目录变为Git 管理的仓库

$ git init

这个目录是一个git仓库，该目录下会多一个.git的目录，来跟踪版本库。

把文件添加到版本库

比如说添加test.java文件（这个文件需在git仓库中，比如之前创建的learngit目录）

• 第一步：把文件添加到仓库

$ git add test.java

在这里也可以添加多个文件，比如：

$ git add file2.txt file3.txt

• 第二步：把文件提交到仓库

$ git commit -m "wrote a readme file"

-m后面输入的是本次提交的说明

文件状态查看

• git status命令可以让我们时刻掌握仓库当前的状态

$ git status

上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改。

• 查看具体修改了什么内容

$ git diff readme.txt

版本回退

• 用git log命令查看历史记录

$ git log

• 如果输出信息过多加上--pretty=oneline参数

$ git log --pretty=oneline

每一次提交都会有一个版本号记录。

• 回退到上一个版本

$ git reset --hard HEAD^

• 万一我们后悔了，又想回到最新的版本呢

$ git reset --hard 1094a

这里的1094a是版本号，版本号不需要写全，git会自动搜索。

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL：

┌────┐
│HEAD│
└────┘
   │
   └──> ○ append GPL
        │
        ○ add distributed
        │
        ○ wrote a readme file

改为指向add distributed：

┌────┐
│HEAD│
└────┘
   │
   │    ○ append GPL
   │    │
   └──> ○ add distributed
        │
        ○ wrote a readme file

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

• Git提供了一个命令git reflog用来记录你的每一次命令：

$ git reflog

工作区与暂存区

工作区（Working Directory）

比如我的learngit文件夹就是一个工作区：

版本库（Repository）

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

撤销修改

• git checkout -- file可以丢弃工作区的修改：

$ git checkout -- readme.txt

命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次git commit或git add时的状态。

• git reset HEAD <file>撤销暂存区的修改

$ git reset HEAD readme.txt

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

删除文件

• 从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

$ git rm test.txt
$ git commit -m "remove test.txt"

注意：命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

远程仓库（GitHub）

由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

• 第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

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

你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。

如果一切顺利的话，可以在用户主目录里找到.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，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库：
• 在Repository name填入learngit，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库：

目前，在GitHub上的这个learngit仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。

现在，我们根据GitHub的提示，在本地的learngit仓库下运行命令：

$ git remote add origin git@github.com:michaelliao/learngit.git

请千万注意，把上面的michaelliao替换成你自己的GitHub账户名，否则，你在本地关联的就是我的远程库，关联没有问题，但是你以后推送是推不上去的，因为你的SSH Key公钥不在我的账户列表中。

添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

下一步，就可以把本地库的所有内容推送到远程库上：

$ git push -u origin master

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。

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

$ git push origin master

删除远程库

如果添加的时候地址写错了，或者就是想删除远程库，可以用git remote rm <name>命令。使用前，建议先用git remote -v查看远程库信息：

$ git remote -v
origin  git@github.com:michaelliao/learn-git.git (fetch)
origin  git@github.com:michaelliao/learn-git.git (push)

然后，根据名字删除，比如删除origin：

$ git remote rm origin

此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。

从远程库克隆

现在，假设我们从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。

• 首先，登陆GitHub，创建一个新的仓库，名字叫gitskills
• 我们勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件
• 现在，远程库已经准备好了，下一步是用命令git clone克隆一个本地库：

$ git clone git@github.com:michaelliao/gitskills.git

创建与合并分支

在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

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

$ git checkout -b dev

• git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ git branch dev
$ git checkout dev

• 然后，用git branch命令查看当前分支：

$ git branch

• dev分支的工作完成，我们就可以切换回master分支

$ git checkout master

• 我们把dev分支的工作成果合并到master分支上：

$ git merge dev

• 合并完成后，就可以放心地删除dev分支了：

$ git branch -d dev

switch

我们注意到切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。

实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：

创建并切换到新的dev分支，可以使用：

$ git switch -c dev

直接切换到已有的master分支，可以使用：

$ git switch master

使用新的git switch命令，比git checkout要更容易理解。

解决冲突

人生不如意之事十之八九，合并分支往往也不是一帆风顺的。

• 准备新的feature1分支，继续我们的新分支开发：

$ git switch -c feature1

• 现在，master分支和feature1分支各自都分别有新的提交，变成了这样：
  

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

• Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容

果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件。

再提交：

$ git add readme.txt 
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed

现在，master分支和feature1分支变成了下图所示：

• 用带参数的git log也可以看到分支的合并情况：

$ git log --graph --pretty=oneline --abbrev-commit

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

用git log --graph命令可以看到分支合并图。

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

• 准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev

• 可以看到，不使用Fast forward模式，merge后就像这样：
  

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

Bug分支

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

• 要查看远程库的信息，用git remote：

$ git remote

• 用git remote -v显示更详细的信息：

$ git remote -v

抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

• 你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送，出现冲突
  Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：

$ git pull

因此，多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin <branch-name>推送自己的修改；
2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

Rebase

在上一节我们看到了，多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。

• 把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。

$ git rebase

• rebase操作可以把本地未push的分叉提交历史整理成直线；
• rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

.gitignore忽略配置（提交到git时，忽略部分文件）

在根目录下创建.gitignore文件，添加下方内容代表忽略该文件或该文件夹下文件不被Git追踪，即不会提交。

注意：新加.gitignore只能忽略那些原来没有被提交过的文件，如果某些文件已经被纳入了版本管理中，则修改.gitignore是无效的。

target/
.settings/
.idea/
.mvn/
*.classpath
*.options
*.project

参考资料：
Git教程
git merge 与 git rebase的区别