Git : 每一行命令都算数（git 所有命令）-开源-知优网

为了说明我们日常开发中执行的一系列Git命令的作用是什么，我们需要了解Git的工作区域的概念，几乎每一个常见的Git命令操作都可以通过工作区域来解释。

本文转载自微信公众号「sowhat1412」，作者sowhat1412。转载本文请联系sowhat1412公众号。

Git思维导图

Git工作区域

为了说明我们日常开发中执行的一系列Git命令的作用是什么，我们需要了解Git的工作区域的概念，几乎每一个常见的Git命令操作都可以通过工作区域来解释。

Git本地有四个工作区域：

工作区(Working Directory)：在git init之后的本地的文件目录下，也就是大家写代码的地方
暂存区(Staged/Index)：修改了代码之后，需要先将改动add到暂存区，表示将要提交的改动
本地仓库(Local Repository)：本地Git仓库，通俗讲就是本地隐藏文件.git目录下，存储着你的所有改动
远程仓库(Remote Repository)：远程Git仓库，理论上和本地仓库地位平等，但是主要是用于多个开发者之间pull/push代码的仓库。

四个工作区域

Git 文件状态

接下来我们来看下Git文件的状态：

Git 文件状态

UnTracked: 未跟踪，此文件在文件夹中，但并没有加入到git库，不参与版本控制。通过git add 状态变为Staged。
UnModify: 文件已经入库，未修改，即版本库中的文件快照内容与文件夹中完全一致。这种类型的文件有两种去处，如果它被修改，而变为Modified。如果使用git rm移出版本库，则成为UnTracked文件。
Modified: 文件已修改，仅仅是修改，并没有进行其他的操作。这个文件也有两个去处，通过git add可进入暂存staged状态，使用git checkout 则丢弃修改过，返回到unmodify状态，这个git checkout即从库中取出文件，覆盖当前修改。
Staged: 暂存状态，执行git commit则将修改同步到库中，这时库中的文件和本地文件又变为一致，文件为UnModify状态。执行git reset 取消暂存，文件状态为Modified。

Git 基本命令

在了解Git工作区域、文件状态以及本地仓库的相关信息之后，相信大家对于日常使用的一些命令都有了更加深刻的理解。接下来，我们一起进行一个常用命令总结：

git clone：将远程仓库克隆到本地，也就是创建了一个本地仓库，会出现隐藏文件.git
git status：查看状态，可以看到哪些文件被修改、哪些是未跟踪的文件
git diff：可以看到当前工作区和暂存区staged中的文件diff
git add：将未跟踪(新增加)或者修改过的文件从工作区添加到暂存区staged中
git commit：将暂存区staged中的内容提交到本地Git仓库中
git push：将本地Git仓库中的内容提交到远程Git仓库中

并且如果是单人开发，自己玩的情况下，貌似这些命令就足够了。但是，在实际的开发当中，我们往往会面对更加复杂的场景，需要一些更为复杂的命令来处理，我们接着往下看。

git merge

在当前分支上执行git merge master可以将master的提交合并merge到当前分支，也就是更新本地分支。我们日常开发中，将本地代码推到远程仓库，建立Merge Request，然后点击Merge按钮其实就是在master分支上merge了开发分支。

git fetch

git fetch可以将远程分支拉到本地:

git fetch 会将所有远程分支都拉到本地

git fetch origin sowhat1412 指定拉取远程origin仓库的sowhat1412分支到本地

git pull

当我们想要更新本地分支代码的时候，需要将远程开发分支或者远程master分支代码拉到本地，并且合并到当前开发分支上。所以git pull = git fetch + git merge

在当前开发分sowhat1412上，我们执行如下的命令：

gitpulloriginmaster
表示将远程master分支拉到本地并且merge到当前分支sowhat1412上

git rebase

rebase会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。

举例:如果你从 master 拉了个feature分支出来,然后你提交了几个 commit,这个时候刚好有人把他开发的东西合并到 master 了,这个时候 master 就比你拉分支的时候多了几个 commit,如果这个时候你 rebase master 的话，就会把你当前的几个 commit，放到那个人 commit 的后面。

git rebeae

merge 会把公共分支和你当前的commit 合并在一起，形成一个新的 commit 提交

git merge

git cherry-pick

对于多分支的代码库，将代码从一个分支转移到另一个分支是常见需求。

这时分两种情况。一种情况是，你需要另一个分支的所有代码变动，那么就采用合并(git merge)。另一种情况是，你只需要部分代码变动(某几个提交)，这时可以采用 Cherry pick。

git cherry-pick命令的作用，就是将指定的提交(commit)应用于其他分支。

$gitcherry-pick<commitHash>

上面命令就会将指定的提交commitHash，应用于当前分支。这会在当前分支产生一个新的提交，当然它们的哈希值会不一样。

举例来说，代码仓库有master和feature两个分支。

a-b-c-dMaster
\
e-f-gFeature

现在将提交f应用到master分支。

#切换到master分支
$gitcheckoutmaster
#Cherrypick操作
$gitcherry-pickf

上面的操作完成以后，代码库就变成了下面的样子。

a-b-c-d-fMaster
\
e-f-gFeature

从上面可以看到，master分支的末尾增加了一个提交f。

git cherry-pick命令的参数，不一定是提交的哈希值，分支名也是可以的，表示转移该分支的最新提交。

$gitcherry-pickfeature
上面代码表示将feature分支的最近一次提交，转移到当前分支。

Cherry pick 支持一次转移多个提交。

$gitcherry-pick<HashA><HashB>

如果想要转移一系列的连续提交，可以使用下面的简便语法。

$gitcherry-pickA..B

上面的命令可以转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置：提交 A 必须早于提交 B，否则命令将失败，但不会报错。

注意，使用上面的命令，提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A，可以使用下面的语法。

$gitcherry-pickA^..B

git reset

git reset commitId

该命令执行之后，HEAD指针会移动到选中commitId上，并且之前的HEAD->commitId之间的所有修改的内容会被置于工作区，需要重新add、commit。

git reset --soft commitId

$gitcherry-pick<commitHash>
0

git reset --hard commitId

$gitcherry-pick<commitHash>
1

git reflog

新建一个目录git-test，初始化一下仓库，做一次简单的提交

$gitcherry-pick<commitHash>
2

假设这几个星期你做了三次重要代码的提交：

$gitcherry-pick<commitHash>
3

就在这个时候，假设你头脑突然短路，用了git reset这条命令：

$gitcherry-pick<commitHash>
4

再来看一下代码的情况：

$gitcherry-pick<commitHash>
5

有没有什么办法补救呢?答案是肯定的!

用git reflog来看一下

$gitcherry-pick<commitHash>
6

其中，我们可以清楚地看到HEAD每次移动的情况以及哈希值，于是乎我们再采用git reset去试一下：

$gitcherry-pick<commitHash>
7

我们再来看一下代码的情况：

$gitcherry-pick<commitHash>
8

此时用 git log 或 git log --pretty=oneline 可以看到全部的历史记录又恢复回来了。

git revert

revert 是回滚某个 commit ，不是回滚到某个。git revert是用于反做某一个版本，以达到撤销该版本的修改的目的。比如，我们commit了三个版本(版本一、版本二、版本三)，突然发现版本二不行(如：有bug)，想要撤销版本二，但又不想影响撤销版本三的提交，就可以用 git revert 命令来反做版本二，生成新的版本四，这个版本四里会保留版本三的东西，但撤销了版本二的东西。如下图所示：

反做，使用“git revert -n 版本号”命令。如下命令，我们反做版本号为8b89621的版本：

$gitcherry-pick<commitHash>
9

这里可能会出现冲突，那么需要手动修改冲突的文件。而且要git add 文件名来提交

a-b-c-dMaster
\
e-f-gFeature
0

手动整理commit

有这样一个需求，代码量不多，但是因为你多次提交，会导致在建立Merge Request的时候，出现了几十个commitId，比如：“update”、“bug fix”、“fix again”等，不光看起来很丑，也会给大家一种感觉，这小伙到底行不行呀?一百行代码的开发量，提交了这么多次才搞定。(尴尬.jpg)

为了解决这样的问题，我们可以巧妙的利用git reset。比如当前的commit是这样的A-1-2-3-4-5-6-7-8，你的第一个提交是1，那么我们执行如下的命令：

a-b-c-dMaster
\
e-f-gFeature
1

-f是什么操作?force的含义，表示强行执行本次操作。当我们git reset之后，本地的HEAD指针指向的commitId会比远程origin对应的落后，直接push会被拒绝。通过-f命令可以强行将本地内容push到远程分支上(切记!如果是多人共同合作的开发分支或者远程master操作，千万不能加-f操作!!!)

经过git reset --soft之后，我们提的Merge Request里就是一个commitId了，发出来的CR会感觉倍儿有面儿。