Git 常用命令详解

前言：在现在的企业项目开发中大部分已经是使用Git作为项目版本管理工具了，当然我们公司也不例外。对于我个人来说这两年使用Git主要是通过GUI（图形界面）实现的，比如咱们安卓中的AndroidStudio Git操作，在碰见GUI不支持的功能时才是通过Git命令行实现的。以至于最近发现自己对于git命令越来越生疏了，所以今天再把git命令重新梳理一下就当是回顾温习了。

废话不多说了，下面直接开始对每个命令做说明吧。

初始化配置

#配置使用git仓库的人员姓名  
git config [--global] user.name "user"
#配置使用git仓库的人员email  
git config [--global] user.email "user@gmail.com"  
#列举所有配置  
git config -list

添加操作

git add <filename>     //添加某个文件到暂存区（stage)
git add -A             //保存所有的修改
git add .              //保存新的添加和修改，但是不包括已经删除的
git add -u             //保存修改和删除，但是不包括新建文件
所以默认使用git add -A就行

提交操作

git commit -m "你的注释"             //提交到本地库(必须先add)
git commit -a                     //相当于运行 git add -u把所有当前目录下的文件加入缓存区域再运行git commit.注意！对于新增的文件，并没有被commit
git commit -am  “本次提交描述” 或者 或者git commit –a –m“本次提交描述” //可提交未add文件
git commit --amend -m [message] //这个命令会将暂存区中的文件提交。 如果自上次提交以来你还未做任何修改(例如，在上次提交后马上执行了此命令)，那么快照会保持不变，而你所修改的只是提交信息。

# 提交暂存区的指定文件到仓库区
git commit [file1] [file2] ... -m [message]
# 提交时显示所有diff信息
git commit -v

删除操作

git rm <file>             //从暂存区删除文件（stage)  
git rm -f <file>          //删除之前修改过并且已经放到暂存区域
git rm --cached <file>    //如果把文件从暂存区域移除，但仍然希望保留在当前工作目录中，换句话说，仅是从跟踪清单中删除

撤销操作

在Git中，用HEAD表示当前版本：

git HEAD
git HEAD~        //上一个版本
git HEAD~100     //往上100个版本

撤销add

git checkout <file>          //恢复未提交的文件更改
git checkout .               //恢复全部未提交的文件更改
git checkout --hard HEAD     //回退工作区的全部文件修改
git reset HEAD <file>        //取消之前 git add 添加

撤销commit

1. git reset    ：版本直接回退，简单粗暴,如果远程分支也想要回退，git push -f (known changes)。

git reset HEAD^ ：回退版本，一个^表示一个版本，可以多个，另外也可以使用 git reset HEAD~n这种形式。

也可以回退到指定版本：git reset commit-id 。

git reset根据–soft –mixed –hard，会对working tree和index和HEAD进行重置：

soft 参数：git reset --soft HEAD~1 意为将版本库软回退1个版本，所谓软回退表示将本地版本库的头指针全部重置到指定版本，且将这次提交之后的所有变更都移动到暂存区。

默认的mixed参数：git reset HEAD～1 意为将版本库回退1个版本，将本地版本库的头指针全部重置到指定版本，且会重置暂存区，即这次提交之后的所有变更都移动到工作区。

hard参数：git reset --hard HEAD～1 意为将版本库回退1个版本，但是不仅仅是将本地版本库的头指针全部重置到指定版本，也会重置暂存区，并且会将工作区代码清空（工作区是clean状态）。

友情提示：soft参数与默认参数（mixed）都不会修改工作区代码，只有hard参数才会修改工作区代码。另外，git reset HEAD filename  回退文件，将文件从暂存区回退到工作区（unstage），此时不能带hard,soft参数。

2. git revert  ：如果不小心提交了不想要的代码，而小伙伴在你发现时，也已经提交了，这时候就不能简单的回退版本。这时需要通过revert创建要否定的提交。

git revert HEAD //撤销前一次commit
git revert HEAD~3 //revert指定倒数第四个commit
git revert <commit ID> //需要撤销的提交ID

revert过程有可能遇到冲突，要么git revert --abort终止此次revert操作，代码还原至revert命令前。要么手动消除冲突(同普通的冲突解决)，然后add 、commit、push提交到远程分支。

 

git revert 和 git reset的区别：

1.git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。

2.在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入。

3.git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。 

 

远程分支操作

1. git pull ：将远程存储库中的更改合并到当前分支中。

在默认模式下，git pull是git fetch后跟git merge FETCH_HEAD的缩写。更准确地说，git pull使用给定的参数运行git fetch，并调用git merge将检索到的分支头合并到当前分支中。 使用--rebase，它运行git rebase而不是git merge。

也就是说：

git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase

常用pull命令：
git pull                         # 抓取远程仓库所有分支更新并合并到本地    
git pull <远程主机名> <远程分支名>:<本地分支名> // 取回远程主机某个分支的更新，再与本地的指定分支合并

2. git fetch : git中都是fetch命令是将远程分支的最新内容拉到了本地，但是fetch后是看不到变化的，此时本地多了一个FETCH_HEAD的指针，checkout到该指针后可以查看远程分支的最新内容。

git fetch origin                 # 抓取远程仓库更新 

3. git push 

git push                         # push所有分支  
git push origin master           # 将本地主分支推到远程主分支  
git push -u origin master        # 将本地主分支推到远程(如无远程主分支则创建，用于初始化远程仓库)  
git push origin <local_branch>   # 创建远程分支， origin是远程仓库名  
git push origin <local_branch>:<remote_branch>  # 创建远程分支  
git push origin :<remote_branch>  #如果省略本地分支名，则表示删除指定的远程分支，因为这等同于推送一个空的本地分支到远程分支。等同于：
git push origin --delete master

 4. git remote 

git remote -v                    # 查看远程服务器地址和仓库名称  
git remote show origin           # 查看远程服务器仓库状态  
git remote add origin git@ github:robbin/robbin_site.git         # 添加远程仓库地址  
git remote set-url origin git@ github.com:robbin/robbin_site.git # 设置远程仓库地址(用于修改远程仓库地址)  
git remote rm <repository>       # 删除远程仓库  

查看操作

1. git status  可以查看哪些文件处于什么状态：

git status -s | git status --short //得到一种更为紧凑的格式输出

2. git diff   显示add与commit的改动区别。

git diff HEAD               //查看已缓存的与未缓存的所有改动
git diff --stat             //显示摘要而非整个 diff
git diff <file>             // 比较当前文件和暂存区文件差异  
git diff <$id1> <$id2>      // 比较两次提交之间的差异  
git diff <branch1>..<branch2> // 在两个分支之间比较  
git diff --staged           // 比较暂存区和版本库差异  
git diff --cached           // 比较暂存区和版本库差异  

3. git log   回顾提交历史时最简单而又有效的工具是 git log 命令。

git log
git log -2          //仅显示最近两次提交

4. git reflog   git reflog 可以查看所有分支的所有操作记录（包括commit和reset的操作），包括已经被删除的commit记录，git log则不能察看已经删除了的commit记录。

git reflog

友情提示：比如说需要回退到某个commit，只需要：git reset --hard <commit id> 即可，这个命令对于找回丢失的代码非常有用。

5. git help 

git help
git help <command>  // 显示command的help  

6. git show

git show $id        // 显示某次提交的内容  

分支操作

1.创建分支：

git branch <branch name>               //创建分支
git checkout <branch name>             //切换到分支
git checkout -b <branch name>          //创建并切换到分支
git checkout -b <new_branch> <branch>  //基于branch创建新的new_branch  

2.删除分支：

git branch -d <branch name>
git branch -D <branch name>       //强制删除分支(未被合并的分支被删除的时候需要强制)  

3.查看分支：

git branch 
git branch -a      //查看所有分支
git branch -r      //查看远程分支

4.重命名分支：

git branch -m <old name> <new name>

5.合并分支：

git merge : 将 origin 分支合并到 mywork 分支最简单的办法就是用下面这些命令.

git checkout mywork
git merge origin

或者，你也可以把它们压缩在一行里:

git merge origin mywork

merge 命令简介：

假设远程分支上有3次提交A,B,C，在远程分支origin的基础上创建一个名为"mywork"的本地分支并提交了修改E，同时有其他人在"origin"上做了一些修改并提交了修改D。用git merge命令把"origin"分支与本地提交合并（merge）成版本M，mywork 分支中新的合并提交（merge-commit）将两个分支的历史连在了一起，但这样会形成图中的菱形，让人很困惑。

 

Merge 好在它是一个安全的操作，比较安全，现有的分支不会被更改，避免了 rebase 潜在的缺点（后面会说）。另一方面，这同样意味着每次合并上游更改时 feature 分支都会引入一个外来的合并提交。如果 master非常活跃的话，这或多或少会污染你的分支历史。虽然高级的 git log 选项可以减轻这个问题，但对于开发者来说，还是会增加理解项目历史的难度。

git rebase ： 作为 merge 的替代选择，你可以像下面这样将 mywork 分支并入 origin 分支。

git checkout mywork
git rebase origin

它会把整个 mywork 分支移动到 origin 分支的后面，有效地把所有 master 分支上新的提交并入过来。但是，rebase为原分支上每一个提交创建一个新的提交，重写了项目历史，并且不会带来合并提交。rebase的好处是避免了菱形的产生，保持提交曲线为直线，让大家易于理解。

rebase 简介：

rebase最大的好处是你的项目历史会非常整洁。首先，它不像 git merge 那样引入不必要的合并提交。其次，rebase 导致最后的项目历史呈现出完美的线性——你可以从项目终点到起点浏览而不需要任何的 fork。这让你更容易使用 git log、git reset 和 gitk 来查看项目历史。不过这种简单的提交历史会带来两个后果：安全性和可跟踪性。如果你违反了 rebase 黄金法则，重写项目历史可能会给你的协作工作流带来灾难性的影响。此外，rebase 不会有合并提交中附带的信息——你看不到 mywork 分支中并入了上游的哪些更改。

Rebase的黄金法则：

当你理解rebase是什么的时候，最重要的就是什么时候不能用rebase。git rebase 的黄金法则便是，绝不要在公共的分支上使用它。

比如说，如果你把 master分支rebase到你的feature 分支上会发生什么：

这次 rebase 将 master 分支上的所有提交都移到了 feature 分支后面。问题是它只发生在你的代码仓库中，其他所有的开发者还在原来的 master 上工作。因为 rebase 引起了新的提交，Git 会认为你的 master 分支和其他人的 master 已经分叉了。

同步两个 master 分支的唯一办法是把它们 merge 到一起，导致一个额外的合并提交和两堆包含同样更改的提交。不用说，这会让人非常困惑。

所以，在你运行 git rebase 之前，一定要问问你自己「有没有别人正在这个分支上工作？」。如果答案是肯定的，那么把你的爪子放回去，重新找到一个无害的方式（如 git merge）来提交你的更改。不然的话，你可以随心所欲地重写历史。

rebase的过程中,也许会出现冲突,Git会停止rebase并让你解决冲突,在解决完冲突之后,用git add去更新这些内容,然后无需执行commit,只需要:

git rebase --continue   //就会继续打余下的补丁.
git rebase --abort      //将会终止rebase, 当前分支将会回到rebase之前的状态.

友情提示：在任何时候，都可以用git rebase --abort参数来终止rebase的行动，并且mywork分支会回到rebase开始前的状态。

6. 提取其他分支提交： 用cherry-pick，您可以从其他分支复制指定的提交，然后导入到现在的分支。

git cherry-pick <commit id>

标签操作

1.创建标签：

git tag -a <name>    //-a参数会允许你添加一些信息, 当你运行该命令的时候,Git会打开一个编辑器让你输入tag信息.
# 新建一个tag在当前commit
$ git tag [tag]
# 新建一个tag在指定commit
$ git tag [tag] [commit]
# 删除本地tag
$ git tag -d [tag]
# 删除远程tag
$ git push origin :refs/tags/[tagName]
# 查看tag信息
$ git show [tag]
# 提交指定tag
$ git push [remote] [tag]
# 提交所有tag
$ git push [remote] --tags

友情提示：push的时候是不包含tag的,如果想包含,可以在push时加上--tags参数. 

2.查看标签：

git tag // 列出所有的标签
git tag -l 'tag1*'  // 列出所有tag1开头的标签
git show tag1.0  // 查看名为tag1.0相关的信息
git ls-remote --tags  // 查看所有远端的标签

3.删除标签：

git tag -d <name>

获取Git仓库

#在本地新建一个repo,进入一个项目目录,执行gitinit,会初始化一个repo
git init  
#Clone远程版本库，clone下来的repo会以url最后一个斜线后面的名称命名,创建一个文件夹,如果想要指定特定的名称,可以git clone [url] newname指定.
git clone [url] 
#添加远程版本库origin，语法为 git remote add [shortname] [url]  
git remote add origin git@xbc.me:wordpress.git  

代码提交流程

 

1. git add -A
2. git commit -m "message"
3. git pull --rebase (或者git fetch + git rebase）
4. 解决冲突
5. git add 冲突文件
6. git rebase –continue
7. git push
8. 其中，3、4、5点，如果没遇到冲突就不用进行，直接push上去
9. 当遇到冲突时，git会提示patch failed，并要我们解决问题了再执行git rebase --continue

 

今天就写这么多了，后续可能会继续补充，see you​​​​​​​