以下是整理的常用 Git 命令清单，几个专用名词的译名如下：

Workspace：工作区
Index / Stage：暂存区
Repository：仓库区（或本地仓库）
Remote：远程仓库

[TOC]

一、新建代码库

# 在当前目录新建一个 Git 代码库
$ git init

# 新建一个目录，将其初始化为 Git 代码库
$ git init [project-name]

# 下载一个项目和它的整个代码历史
$ git clone [url]

二、配置

Git 的设置文件为.gitconfig，它可以在用户主目录下（全局配置），也可以在项目目录下（项目配置）。

# 显示当前的 Git 配置
$ git config –list

# 编辑 Git 配置文件
$ git config -e [–global]

# 设置提交代码时的用户信息
$ git config [–global] user.name “[name]”
$ git config [–global] user.email “[email address]”

三、增加/删除文件

# 添加指定文件到暂存区
$ git add file1 file2…

# 添加指定目录到暂存区，包括子目录
$ git add [dir]

# 添加当前目录的所有文件到暂存区
$ git add .

# 删除工作区文件，并且将这次删除放入暂存区
$ git rm file1 file2…

# 停止追踪指定文件，但该文件会保留在工作区
$ git rm –cached [file]

# 改名文件，并且将这个改名放入暂存区
$ git mv file-original file-renamed

四、代码提交

# 提交暂存区到仓库区
$ git commit -m [message]

# 提交暂存区的指定文件到仓库区
$ git commit file1 file2 … -m [message]

# 提交工作区自上次 commit 之后的变化，直接到仓库区
$ git commit -a

# 提交时显示所有 diff 信息
$ git commit -v

# 使用一次新的 commit，替代上一次提交
# 如果代码没有任何新变化，则用来改写上一次 commit 的提交信息
$ git commit –amend -m [message]

# 重做上一次 commit，并包括指定文件的新变化
$ git commit –amend …

五、分支

# 列出所有本地分支
$ git branch

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

# 列出所有本地分支和远程分支
$ git branch -a

# 新建一个分支，但依然停留在当前分支
$ git branch [branch-name]

# 新建一个分支，并切换到该分支
$ git checkout -b [branch]

# 新建一个分支，指向指定 commit
$ git branch branch commit

# 新建一个分支，与指定的远程分支建立追踪关系
$ git branch –track branch remote-branch

# 切换到指定分支，并更新工作区
$ git checkout [branch-name]

# 建立追踪关系，在现有分支与指定的远程分支之间
$ git branch –set-upstream branch remote-branch

# 合并指定分支到当前分支
$ git merge [branch]

# 选择一个 commit，合并进当前分支
$ git cherry-pick [commit]

# 删除分支
$ git branch -d [branch-name]

# 删除远程分支
$ git push origin –delete

$git push origin :[branch-name]
$ git branch -dr

六、标签

# 列出所有 tag
$ git tag

# 新建一个 tag 在当前 commit
$ git tag [tag]

# 新建一个 tag 在指定 commit
$ git tag tag commit

# 查看 tag 信息
$ git show [tag]

# 提交指定 tag
$ git push remote tag

# 提交所有 tag
$ git push [remote] –tags

# 新建一个分支，指向某个 tag
$ git checkout -b branch tag

七、查看信息

# 显示有变更的文件
$ git status

# 显示当前分支的版本历史
$ git log

# 显示 commit 历史，以及每次 commit 发生变更的文件
$ git log –stat

# 显示某个文件的版本历史，包括文件改名
$ git log –follow [file]
$ git whatchanged [file]

# 显示指定文件相关的每一次 diff
$ git log -p [file]

# 显示指定文件是什么人在什么时间修改过
$ git blame [file]

# 显示暂存区和工作区的差异
$ git diff

# 显示暂存区和上一个 commit 的差异
$ git diff –cached []

# 显示工作区与当前分支最新 commit 之间的差异
$ git diff HEAD

# 显示两次提交之间的差异
$ git diff [first-branch]…[second-branch]

# 显示某次提交的元数据和内容变化
$ git show [commit]

# 显示某次提交发生变化的文件
$ git show –name-only [commit]

# 显示某次提交时，某个文件的内容
$ git show [commit]:[filename]

# 显示当前分支的最近几次提交
$ git reflog

八、远程同步

# 下载远程仓库的所有变动
$ git fetch [remote]

# 显示所有远程仓库
$ git remote -v

# 显示某个远程仓库的信息
$ git remote show [remote]

# 增加一个新的远程仓库，并命名
$ git remote add shortname url

# 删除远程仓库
$ git remote remove [shortname]

# 取回远程仓库的变化，并与本地分支合并
$ git pull remote branch

# 上传本地指定分支到远程仓库
$ git push remote branch

# 强行推送当前分支到远程仓库，即使有冲突
$ git push [remote] –force

# 推送所有分支到远程仓库
$ git push [remote] –all

九、撤销

# 恢复暂存区的指定文件到工作区
$ git checkout [file]

# 恢复某个 commit 的指定文件到工作区
$ git checkout commit file

# 恢复上一个 commit 的所有文件到工作区
$ git checkout .

# 重置暂存区的指定文件，与上一次 commit 保持一致，但工作区不变
$ git reset [file]

# 重置暂存区与工作区，与上一次 commit 保持一致
$ git reset –hard

# 重置当前分支的指针为指定 commit，同时重置暂存区，但工作区不变
$ git reset [commit]

# 重置当前分支的 HEAD 为指定 commit，同时重置暂存区和工作区，与指定 commit 一致
$ git reset –hard [commit]

# 重置当前 HEAD 为指定 commit，但保持暂存区和工作区不变
$ git reset –keep [commit]

# 新建一个 commit，用来撤销指定 commit
# 后者的所有变化都将被前者抵消，并且应用到当前分支
$ git revert [commit]

十、其他

# 生成一个可供发布的压缩包
$ git archive

Git撤销修改

自然，你是不会犯错的。不过现在是凌晨两点，你正在赶一份工作报告，你在readme.txt中添加了一行：

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.

在你准备提交前，一杯咖啡起了作用，你猛然发现了stupid boss可能会让你丢掉这个月的奖金！

既然错误发现得很及时，就可以很容易地纠正它。你可以删掉最后一行，手动把文件恢复到上一个版本的状态。如果用git status查看一下：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

你可以发现，Git会告诉你，git checkout -- file可以丢弃工作区的修改：

1	$ git checkout -- readme.txt

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

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

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

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

现在，看看readme.txt的文件内容：

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

文件内容果然复原了。

git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令

Git fetch和pull的详解及区别

git fetch和pull的区别

Git中从远程的分支获取最新的版本到本地有这样2个命令：

git fetch：相当于是从远程获取最新版本到本地，不会自动merge

1
2
3

Git fetch origin master
git log -p master..origin/master
git merge origin/master

以上命令的含义：

首先从远程的origin的master主分支下载最新的版本到origin/master分支上；然后比较本地的master分支和origin/master分支的差别；最后进行合并。上述过程其实可以用以下更清晰的方式来进行：

1
2
3

git fetch origin master:tmp
git diff tmp 
git merge tmp

从远程获取最新的版本到本地的tmp分支上之后再进行比较合并

git pull：相当于是从远程获取最新版本并merge到本地

1	git pull origin master

上述命令其实相当于git fetch 和 git merge 在实际使用中，git fetch更安全一些。因为在merge前，我们可以查看更新情况，然后再决定是否合并结束。

Git merge 与 rebase

git merge

来看两种场景中merge的不同方式。

场景一：切出特性分支后，develop分支上没有新的提交。

fast-forward，若无分歧，会直接移动文件指针。看不出特性分支的起始点。

no-fast-forward（–no-ff），保留提交链的完整性。

squash，压缩不必要的commit；无法看出feature分支合到develop；feature，develop保持相对独立。

场景二：切出特性分支后，develop分支上提交了C6，C7。

develop分支上提交了C6，C7，无法fast forward。

three way merge，

找到develop分支的最新节点C7；

找到feature分支的最新节点C5；

找到develop分支和feature分支的共同祖先节点C3；

对C3，C5，C7进行三方合并，生成最新的C8。

git rebase

变基/衍合，从旧的base变基到新的base，在新base的基础上重现另一个分支的修改过程，版本树像两个链条串在一起变成一个链条，以达到线性的效果。

rebase，对指定的base本身并没有什么影响；只是重写base之后的commit历史。

来看几个场景：

在继续开发的过程中和主分支develop同步

从develop上拉出分支做一些开发工作，在这个过程中develop分支可能继续往前走了，那我们需要经常和develop保持下同步（可能是别人提交了公用的模块，或者修复了对大家都有影响的bug）。之前我会通过pull操作来达到这一目的，但pull往往内置了merge（pull的效果看起来就像fetch+merge，想想提到过的“merge应该反映业务层面的合并，而非技术行为”，并且此时merge会产生一些杂乱的历史记录）。

这就相当于我们本地的开发工作（一系列的commits）是在旧的base上展开的，应该使用rebase操作，将本地的开发工作变基到develop的最新节点上。

1	git pull --rebase

重新拾起搁置的工作

很久之前可能启动一个并行工作（开发不着急上线的新特性或者优化一些功能），但一直没有时间处理所以就搁置了，现在又有时间重新拾起，然后就发现当时基于的base实在是太太太老了。现在肯定是希望基于最新的base展开工作，这样就可以从已解决的bugfix或已完成的新特性中中受益。

在push之前整理我的本地历史

1	git rebase -i <myBaseCommit>

这是一个使用更频繁的场景：并不是为了变基，而是清理本地的commit。很多情况我们都需要commit：

可能需要多个连续的commit才能完成一次bugfix；

切换分支需要保存本地修改（当然按理说这个时候应该使用stash或者idea提供的shelve了）；

某些历史commit写错了msg（最近一次commit的msg可以通过 commit –amend 修改）；

通过-i（–interactive，交互式的），我们可以干预rebase将要执行的脚本化过程，从而达到清理本地commit历史的目的。

熟练使用rebase，可以轻松的进行commit，只需要在最终push之前做一次清理，不必担心影响到公共仓库。

git fetch origin develop
git rebase origin/develop
... do sth ...
git push

rebase的场景和用法还有待探索，慢慢更新了。

记住这个：

只能rebase私有分支，一旦发布到公共仓库，不要再rebase了。

merge V.S. rebase

什么时候用merge；基于上述不同的merge行为（fast-forward，–no-ff，squash），什么场景下用哪种merge：

merge执行一个合并，这个合并应该反应业务层面的合并，而非技术行为。我们希望在当前分支上往前走，这样它就包含了其他分支的工作。

所以问题的关键是：这个“其他分支”是什么样的分支？这个“其他分支”需要在历史图谱中展示么？

本地的、临时的分支，使用它仅仅是为了使master保持clean。

1.若拉出本地分支后，master往前走了，此时在本地分支：

1	git rebase -i master

将本地分支变基到最新的master节点（重新梳理本地历史提交信息比如合并成一个commit），好似本地分支就是在最新的master节点上做的开发工作，以保证合并到master后呈现线性增长。

2.在master上：

1	git merge (fast-forward)

最终以一个或几个commit展现在master上。

知名分支，团队明确定义的，可能是用来追踪bug/feature。

永远不要用rebase，而是用

1	git merge --no-ff

以保留清晰完整的历史图谱。

master分支执行merge不应该存在冲突，merge过程需要加入--no-ff，记录合并过程，保留分支历史记录

在个人分支上，落后于master，先执行rebase，并且整理好commit，再回到master执行如上的merge

rebase示例

参考：https://www.jianshu.com/p/4a8f4af4e803

合并多个commit为一个完整commit

当我们在本地仓库中提交了多次，在我们把本地提交push到公共仓库中之前，为了让提交记录更简洁明了，我们希望把如下分支B、C、D三个提交记录合并为一个完整的提交，然后再push到公共仓库。

现在我们在测试分支上添加了四次提交，我们的目标是把最后三个提交合并为一个提交：

这里我们使用命令:

1	git rebase -i [startpoint] [endpoint]

其中-i的意思是--interactive，即弹出交互式的界面让用户编辑完成合并操作，[startpoint] [endpoint]则指定了一个编辑区间，如果不指定[endpoint]，则该区间的终点默认是当前分支HEAD所指向的commit(注：该区间指定的是一个前开后闭的区间)。
在查看到了log日志后，我们运行以下命令：

1	git rebase -i 36224db

或:

1	git rebase -i HEAD~3

然后我们会看到如下界面:

上面未被注释的部分列出的是我们本次rebase操作包含的所有提交，下面注释部分是git为我们提供的命令说明。每一个commit id 前面的

pick

表示指令类型，git 为我们提供了以下几个命令:

pick：保留该commit（缩写:p）

reword：保留该commit，但我需要修改该commit的注释（缩写:r）

edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）

squash：将该commit和前一个commit合并（缩写:s）

fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）

exec：执行shell命令（缩写:x）

drop：我要丢弃该commit（缩写:d）

根据我们的需求，我们将commit内容编辑如下:

然后是注释修改界面:

编辑完保存即可完成commit的合并了：

注意事项：如果这个过程中有操作错误，可以使用 git rebase --abort来撤销修改，回到没有开始操作合并之前的状态。

git多人合作流程

针对于merge合并分支的流程

做几个假设:线上只有一条origin。
张三, 李四，王五都从origin上clone一个master分支
张三在本地master分支上，创建一个zhangsan分支
张三在zhangan分支上进行工作.工作完成后，切换到master分支
假如这时候origin分支上可能已经被李四或者wa王五提交了多个版本，假如有4个版本了，张三在master分支上pull一下，这时候肯定没有冲突
张三在master分支上，git merge zhangsan, 解决完冲突，然后将master， push上去,这时候张三任务完成，这时候张三如果想继续在zhangsan分支上开发，直接在zhangsan分支上，让指针指向master的最顶端的commit即可

针对rebase合并分支的流程

做几个假设:线上只有一条origin
张三, 李四，王五都从origin上clone一个master分支
张三在本地master分支上，创建一个zhangsan分支
张三在zhangan分支上进行工作.工作完成后，切换到master分支
假如这时候origin分支上可能已经被李四或者wa王五提交了多个版本，假如有4个版本了，张三在master分支上pull一下，这时候肯定没有冲突， pull之后，切换会zhangsan分支
张三在zhangsan分支上，git rebase master, 这时候可能有多个冲突(zhangsan分支commit过几次，就会有几次冲突)，然后一直continue，直到解决完冲突为止。
然后切换回master，在master分支上，指针指向zhangsan分支的顶端（操作方法 git reset –hard zhangsan顶端的commit值）,然后push master上远程仓库这时候张三任务完成