一、Git 命令初识
在正式介绍 Git 命令之前，先介绍一下 Git 的根本命令和操作，对 Git 命令有一个总体的意识
示例：从 Git 版本库的初始化，通常有两种形式：
1）git clone：这是一种较为简单的初始化形式，当你曾经有一个近程的 Git 版本库，只须要在本地克隆一份
例如：git clone git://github.com/someone/some_project.git some_project
下面的命令就是将 ’git://github.com/someone/some_project.git’ 这个 URL 地址的近程版本库，齐全克隆到本地 some_project 目录下
2）git init 和 git remote：这种形式略微简单一些，当你本地创立了一个工作目录，你能够进入这个目录，应用 ’git init’ 命令进行初始化；Git 当前就会对该目录下的文件进行版本控制，这时候如果你须要将它放到近程服务器上，能够在近程服务器上创立一个目录，并把可拜访的 URL 记录下来，此时你就能够利用 ’git remote add’ 命令来减少一个近程服务器端，
例如：git remote add origin git://github.com/someone/another_project.git
下面的命令就会减少 URL 地址为 ’git: //github.com/someone/another_project.git’，名称为 origin 的近程服务器，当前提交代码的时候只须要应用 origin 别名即可
二、Git 常用命令
1) 近程仓库相干命令
检出仓库：$ git clone git://github.com/jquery/jquery.git
查看近程仓库：$ git remote -v
增加近程仓库：$ git remote add [name] [url]
删除近程仓库：$ git remote rm [name]
批改近程仓库：$ git remote set-url –push [name] [newUrl]
拉取近程仓库：$ git pull [remoteName] [localBranchName]
推送近程仓库：$ git push [remoteName] [localBranchName]
* 如果想把本地的某个分支 test 提交到近程仓库，并作为近程仓库的 master 分支，或者作为另外一个名叫 test 的分支，如下：
$git push origin test:master // 提交本地 test 分支作为近程的 master 分支
$git push origin test:test // 提交本地 test 分支作为近程的 test 分支
2）分支 (branch) 操作相干命令
查看本地分支：$ git branch
查看近程分支：$ git branch -r
创立本地分支：$ git branch [name] —- 留神新分支创立后不会主动切换为以后分支
切换分支：$ git checkout [name]
创立新分支并立刻切换到新分支：$ git checkout -b [name]
删除分支：$ git branch -d [name] —- - d 选项只能删除曾经参加了合并的分支，对于未有合并的分支是无奈删除的。如果想强制删除一个分支，能够应用 - D 选项
合并分支：$ git merge [name] —- 将名称为 [name] 的分支与以后分支合并
创立近程分支(本地分支 push 到近程)：$ git push origin [name]
删除近程分支：$ git push origin :heads/[name] 或 $ gitpush origin :[name]
* 创立空的分支：(执行命令之前记得先提交你以后分支的批改，否则会被强制删洁净没得悔恨)
$git symbolic-ref HEAD refs/heads/[name]
$rm .git/index
$git clean -fdx
3）版本 (tag) 操作相干命令
查看版本：$ git tag
创立版本：$ git tag [name]
删除版本：$ git tag -d [name]
查看近程版本：$ git tag -r
创立近程版本(本地版本 push 到近程)：$ git push origin [name]
删除近程版本：$ git push origin :refs/tags/[name]
合并近程仓库的 tag 到本地：$ git pull origin –tags
上传本地 tag 到近程仓库：$ git push origin –tags
创立带正文的 tag：$ git tag -a [name] -m ‘yourMessage’
4) 子模块 (submodule) 相干操作命令
增加子模块：$ git submodule add [url] [path]
如：$git submodule add git://github.com/soberh/ui-libs.git src/main/webapp/ui-libs
初始化子模块：$ git submodule init —- 只在首次检出仓库时运行一次就行
更新子模块：$ git submodule update —- 每次更新或切换分支后都须要运行一下
删除子模块：（分 4 步走哦）
1) $ git rm –cached [path]
2) 编辑“.gitmodules”文件，将子模块的相干配置节点删除掉
3) 编辑“.git/config”文件，将子模块的相干配置节点删除掉
4) 手动删除子模块残留的目录
5）疏忽一些文件、文件夹不提交
在仓库根目录下创立名称为“.gitignore”的文件，写入不须要的文件夹名或文件，每个元素占一行即可，如
target
bin
*.db
三、Git 命令详解
当初咱们有了本地和近程的版本库，让咱们来试着用用 Git 的根本命令：
git pull：从其余的版本库（既能够是近程的也能够是本地的）将代码更新到本地，例如：’git pull origin master’ 就是将 origin 这个版本库的代码更新到本地的 master 主枝，该性能相似于 SVN 的 update
git add：是将以后更改或者新增的文件退出到 Git 的索引中，退出到 Git 的索引中就示意记入了版本历史中，这也是提交之前所须要执行的一步，例如 ’git add app/model/user.rb’ 就会减少 app/model/user.rb 文件到 Git 的索引中，该性能相似于 SVN 的 add
git rm：从以后的工作空间中和索引中删除文件，例如 ’git rm app/model/user.rb’，该性能相似于 SVN 的 rm、del
git commit：提交当前工作空间的批改内容，相似于 SVN 的 commit 命令，例如 ’git commit -m story #3, add user model’，提交的时候必须用 - m 来输出一条提交信息，该性能相似于 SVN 的 commit
git push：将本地 commit 的代码更新到近程版本库中，例如 ’git push origin’ 就会将本地的代码更新到名为 orgin 的近程版本库中
git log：查看历史日志，该性能相似于 SVN 的 log
git revert：还原一个版本的批改，必须提供一个具体的 Git 版本号，例如 ’git revert bbaf6fb5060b4875b18ff9ff637ce118256d6f20’，Git 的版本号都是生成的一个哈希值
下面的命令简直都是每个版本控制工具所私有的，上面就开始尝试一下 Git 独有的一些命令：
git branch：对分支的增、删、查等操作，例如 ’git branch new_branch’ 会从以后的工作版本创立一个叫做 new_branch 的新分支，’git branch -D new_branch’ 就会强制删除叫做 new_branch 的分支，’git branch’ 就会列出本地所有的分支
git checkout：Git 的 checkout 有两个作用，其一是在不同的 branch 之间进行切换，例如 ’git checkout new_branch’ 就会切换到 new_branch 的分支下来；另一个性能是还原代码的作用，例如 ’git checkout app/model/user.rb’ 就会将 user.rb 文件从上一个已提交的版本中更新回来，未提交的内容全副会回滚
git rebase：用上面两幅图解释会比较清楚一些，rebase 命令执行后，实际上是将分支点从 C 移到了 G，这样分支也就具备了从 C 到 G 的性能
git reset：将以后的工作目录齐全回滚到指定的版本号，假如如下图，咱们有 A - G 五次提交的版本，其中 C 的版本号是 bbaf6fb5060b4875b18ff9ff637ce118256d6f20，咱们执行了 ’git resetbbaf6fb5060b4875b18ff9ff637ce118256d6f20’ 那么后果就只剩下了 A - C 三个提交的版本
git reset：将以后的工作目录齐全回滚到指定的版本号，假如如下图，咱们有 A - G 五次提交的版本，其中 C 的版本号是 bbaf6fb5060b4875b18ff9ff637ce118256d6f20，咱们执行了 ’git resetbbaf6fb5060b4875b18ff9ff637ce118256d6f20’ 那么后果就只剩下了 A - C 三个提交的版本
git stash：将以后未提交的工作存入 Git 工作栈中，时机成熟的时候再利用回来，这里临时提一下这个命令的用法，前面在技巧篇会重点解说
git config：利用这个命令能够新增、更改 Git 的各种设置，例如 ’git config branch.master.remote origin’ 就将 master 的近程版本库设置为别名叫做 origin 版本库，前面在技巧篇会利用这个命令个性化设置你的 Git，为你打造举世无双的 Git
git tag：能够将某个具体的版本打上一个标签，这样你就不须要记忆简单的版本号哈希值了，例如你能够应用 ’git tag revert_version bbaf6fb5060b4875b18ff9ff637ce118256d6f20’ 来标记这个被你还原的版本，那么当前你想查看该版本时，就能够应用 revert_version 标签名，而不是哈希值了
Git 之所以可能提供方便的本地分支等个性，是与它的文件存储机制无关的。Git 存储版本控制信息时应用它本人定义的一套文件系统存储机制，在代码根目录下有一个.git 文件夹，会有如下这样的目录构造：
有几个比拟重要的文件和目录须要解释一下：HEAD 文件寄存根节点的信息，其实目录构造就示意一个树型构造，Git 采纳这种树形构造来存储版本信息，那么 HEAD 就示意根；refs 目录存储了你在以后版本控制目录下的各种不同援用（援用指的是你本地和近程所用到的各个树分支的信息），它有 heads、remotes、stash、tags 四个子目录，别离存储对不同的根、近程版本库、Git 栈和标签的四种援用，你能够通过命令 ’git show-ref’ 更清晰地查看援用信息；logs 目录依据不同的援用存储了日志信息。因而，Git 只须要代码根目录下的这一个.git 目录就能够记录残缺的版本控制信息，而不是像 SVN 那样根目录和子目录下都有.svn 目录。那么上面就来看一下 Git 与 SVN 的区别吧