你可能不知道的Git使用方法

使用Git已有很长一段时间，遇到一些痛点问题，而且大都是网上难以直接查到的，故总结于此。

1.两幅重要的图

基础构成

命令原理

以上两幅图对理解Git的原理十分重要。

2.基础命令

首先是一些基础命令，这些命令经常使用，而少为人知。

git add -A 或 git add --all 把包括修改、增加、删除都全部加入暂存区。等同于 git add . 和 git add -u两个命令。
git add -p 一段段地把修改提交到暂存区，每一个修处改都会提示你是否加入暂存区。可以按照想要的方式把所有修改分成多个commit。
git commit -am 把已经加入暂存区(Stage)的文件的更改提交到本地版本库，无论这些更改是否已经加入暂存区。与git commit -m的区别在于后者只能向本地版本库提交已经加入暂存区的更改。如果只是改动某些代码，而没有增加或者删除文件，使用git commit -am一个命令就可以替代git add --all和git commit -m两个命令。
git commit --amend 修改最后一次commit的提交信息。注意，是最后一次，也就是HEAD指向的commit。
git branch -vv 显示本地分支与远程分支的对应关系。执行git push(没有带分支参数)时代码被提交到对应远程分支，就是依据该对应关系。这里需要注意Git的simple和matching模式，后者会一次性提交所有的对应关系的分支的代码到远程分支，前者只会提交当前所在分支。
git stash和git statsh pop 主要用来暂存当前的工作。如果需要git pull又不想把当前的修改提交commit，则可以先使用git stash把修改暂存。该命令运行完后工作区是干净的，此时再使用git pull拉新代码。完事了后使用git statsh pop恢复之前的工作状态。
git reflog 显示曾经的commit。如果我们使用git reset将HEAD指向某个过去的commit了，此时要想回到最开始的commit，使用git log是无法查到最开始的commit的。但是也不要慌，git reflog能给你回到最开始的commit的机会，它会显示所有的提交记录。

3.使用场景

根据一些常见的场景给出我自己的解决方法。

3.1 基于远程分支建立本地分支

你可能刚入职。你的新同事突然丢过来一个地址A，让你git clone一下代码。接着他又丢过来一个分支名dev0.1，让你基于该分支进行开发。如果之前只会在master上git pull和git push，此时就可能有点不知所措了。

你可能首先想到如何把远程的dev0.1分支clone下来，因为执行git clone A之后，你再用git branch查一下，发现本地只有master分支。

这里需要纠正一个问题。git clone A实际上把所有的分支都从远程拉下来了，但是git branch只显示那些与远程保持了追踪(tracked)的分支。并且git clone A还会创建本地master分支并将其与远程(origin)的master建立追踪(tracked)关系。于是我们最开始使用git branch就只显示master了。

那么，问题来了。既然所有分支都已经拉下来了，我们如何切入dev0.1分支并进行开发呢？其实很简单：

git checkout dev0.1

这个命令的含义是将dev0.1分支从本地版本库取到工作区来(参考上面的两幅图中的第二幅)，并将工作区切换到该分支。此时一个本地名为dev0.1的分支与远程(origin)的dev0.1分支就建立了追踪关系。我们就可以基于dev0.1进行开发了。试试git branch看看会不会显示出dev0.1。

假如远程分支中并没有一个叫dev0.1的分支，我们运行以上命令，就会发现这样的错误提示：

error: pathspec 'dev0.1' did not match any file(s) known to git.

此时我们可以看看到底有哪些远程分支，请使用git branch -r。当然git branch -a显示的信息就多一些，它显示全部本地分支和远程分支。

但我通常并不这样做。而是用以下命令：

git checkout -b dev origin/dev0.1

它的含义是新建一个本地分支dev，且让这个分支与远程dev0.1分支保持追踪关系。这样做的好处在于可以自己取一个本地分支名。

3.2 分支开发模式同步Master分支代码

你可能基于本地的dev0.1分支写了一些代码，测试后并提交到本地仓库中了。你们团队代码主干分支是master，且基于这个分支进行发布。这就面临着一个问题，你的新写的代码如何提交到主干分支上。

1.如果的本地dev0.1分支与远程(origin)dev0.1分支保持了追踪关系，且如果你们团队使用类似github/gitlab这样的git仓库托管服务，则可以直接在本地dev0.1分支上操作：

先git pull origin dev0.1拉下远程代码，以防有更新。如果git是simple模式，则可以直接使用git pull[目前git2.0及以上版本都默认为simple模式]。
如果有更新则会自动合并，合并如果失败，则会要求手动处理冲突。处理完后将这次修改提交到本地仓库。
使用git push origin dev0.1向远程仓库dev0.1分支提交代码。git 2.0及以上版本直接git push即可。
在github/gitlab的界面上操作，由dev0.1分支向master分支提交merge请求。负责master分支维护的同事合并你的分支代码到master即可。

2.如果本地dev0.1分支是基于master分支新建的，即在本地master上使用git checkout -b dev0.1命令---它会创建一个dev0.1的本地分支，并切换到该分支，但它不会设置与远程分支的追踪关系。这时候如何将该分支的新代码合并到master分支呢？

首先dev0.1分支要合并到本地master上去。先使用git checkout master切换到主干分支，在主干分支上操作。
合并dev0.1分支。使用git merge dev0.1 --no-ff或git merge dev0.1命令。这两者的区别可用以下图片说明：

两个命令的区别

前者带有分支记录，后者没有。

然后将master分支的代码提交到远程master:git pull拉新代码，解决冲突，git push推到远程。
如果dev0.1分支没用处了，就可以直接删掉：git branch -d dev0.1。

3.3 将工作区恢复成干净的状态

如果开发了一阵子，修改了一些代码，但没控制好，把工作区搞成了一堆乱麻。这时候就想，要是能把工作区恢复成最开始的样子就好了。

首先确定要恢复成的最初状态。一般来讲就是将工作区恢复成当前本地仓库中HEAD所指向的commit。不过如果你之前提交到本地的一些commit你也不想要了，那么先用git log查一下你要恢复到的commitID，复制下来。
使用git reset --hard HEAD/commitID命令。运行完毕之后，用git status查一下状态。一般状态下会显示

nothing to commit, working directory clean

但是如果你最开始时新增了一些文件，且没有将其加入暂存区，那么就不是这种提示了。你需要把你新增的那些文件删掉，git status才会恢复成以上状态。主要原因是git reset无法重置那些没有加入暂存区的更改。

如果你只是需要把某个文件B恢复成仓库里上一次提交的状态，那么有以下两种可能：1.这个文件没有任何修改提交到暂存区；2.这个文件有一部分修改提交到暂存区了，但是想把暂存区的修改也恢复成HEAD指向的版本。

1情况下直接使用git checkout B恢复工作区的文件B。
2情况下先使用git reset HEAD B撤销暂存区里面对B的修改，再使用git checkout B恢复工作区中的修改。

3.4 修改某次的提交信息

这个场景并不常见，而有的时候又一定用的到。例如你开发一段时间了，却发现公司的gitlab要求你push的时候必须使用公司的邮箱，而你之前的commit都用的是你自己的邮箱。我之前就遇到过这个问题，在这儿记录一下解决方案。

首先，git commit --amend只能对最新提交的Comment内容或邮箱的修改，并不能对中间提交的Comment或者邮箱进行修改。如果只是修改最新提交的信息：

git commit --amend 直接进入修改提交信息的模式。
git commit --amend --author="chenyi <chenyi@xxx.com>" 可以修改作者信息。

如果需要修改中间某一次的提交信息，则需要按照一定的方法操作。以下是一个修改示列。

原始记录

如上图，第二个提交的邮箱同其他提交不一样，我们需要将它修改成与其他一样的。

先进入第二个提交：git rebase -i preCommitID，这里preCommitID就是第二个提交的下面的一个ID，即ff4e24。

进入修改模式

我们可以看到，列表里面显示了我们想要修改的commit的ID，即c1c6685。将其前面的pick更改为edit，保存并退出。

提示

当我们从第2步的编辑过程中退出后，git会提示我们可以用的两个命令git commit --amend和git rebae --continue。这两个命令在后面都会用到。

修改模式

我们目前已经处于c1c6685commit上了。此时我们只需要使用git commit --amend --author="chyoo <chyoo1991@gmail.com>"修改该提交的作者信息。上图就是运行该命令后进入修改的界面。

退出之后的结果

退出第4步的修改模式之后，git给的提示信息。接下来我们只需要运行git rebase --continue继续rebase就可以完成目标了。

3.5 将Commit记录变成直线模式

通常很多人合作写代码时，希望将远程master分支维护成直线的形式，这样commit干净明确，检查问题时能省不少事。而一般合并最新代码时用的git pull会将生成一个merge commit，这将导致推送到远程分支的代码也是各种分支交叉，一点也不干净明确。

那么，该如何实现这个目的呢？

首先这里要上一份干货，就是git merge与git rebase的区别，需要注意到git pull实际上是调用git merge进行代码的合并。->干货在此。

从干货文章中我们可以发现，能够使用git rebase命令用打补丁的方式来实现commit保持直线的目的。我们这样操作：

git fetch origin master 用这个命令将远程(origin)的master分支最新提交取到本地。
git rebase origin/master 使用rebase 进行pack打补丁，将我们自己提交的本地代码以补丁的方式放在最新代码的后面。这个过程中可能会出现冲突，修改完了之后使用git rebase --continue继续pack，直到完成rebase。如果出现无法解决的问题，想回到最开始，可以使用git rebase --abort。
git push提交代码到远程master分支。

这里要求开发协作的每一个人都用这种方式操作和提交代码，这样才能保持远程master分支的干净整洁和直线性。

->这一篇文章讲了为什么这样做的原理。

3.6 为一个本地仓库设定多个远程仓库

这个看起来是有点奇怪的需求。不过前不久gitlab的员工删除了它们的数据库，导致很大部分项目受影响，这让我们觉得如果能多一份代码保障或许更好。

使用git clone时，会自动设定远程地址，一般都是以origin指代。如果我们有特殊需求，需要将代码提交到另一个远程仓库，这时就要设定新的远程仓库地址了。

git remote add hegel http://xxxx.git 这个命令就可以给当前的本地库设置一个远程仓库hegel。以后我们想推拉代码到这个远程库时，就需要用git push hegel master或git pull hegel master了。

4.快捷设定

有一些比较有用的设定，能在写命令时少了很多麻烦。

全局设置user和email

git config --global user.name "chenyi"
git config --global user.emali "chenyi@xxx.com"

给常用命令起一个简单的名字

git config --global alias.co checkout
git config --global alias.st status
git config --global alias.br branch
git config --global alias.ci commit

后续就可以使用git co/git ci等命令了，是不是简洁了很多？

3.更好看的git log

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

配置了这个之后，使用git lg简直眼前一亮。