pro git
Git教程

Git是目前世界上最先进的分布式版本控制系统（没有之一）
Linus在1991年创建了开源的Linux--Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！

安装Git

在Windows上安装Git git-download
安装完成后，还需要最后一步设置，在命令行输入：
用户信息
第一个要配置的是你个人的用户名称和电子邮件地址。这两条配置很重要，每次 Git 提交时都会引用这两条信息，说明是谁提交了更新，所以会随更新内容一起被永久纳入历史记录

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

如果用了 --global 选项，那么更改的配置文件就是位于你用户主目录下的那个，以后你所有的项目都会默认使用这里配置的用户信息。如果要在某个特定的项目中使用其他名字或者电邮，只要去掉 --global 选项重新配置即可，新的设定保存在当前项目的 .git/config 文件里。
查看配置信息
要检查已有的配置信息，可以使用 git config --list 命令

$ git config --list

有时候会看到重复的变量名，那就说明它们来自不同的配置文件（比如 /etc/gitconfig 和 ~/.gitconfig），不过最终 Git 实际采用的是最后一个。
也可以直接查阅某个环境变量的设定，只要把特定的名字跟在后面即可，像这样：

$ git config user.name

创建版本库

版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。
创建一个文件夹

首先，选择一个合适的地方，创建一个空目录：
$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
pwd命令用于显示当前目录。
如果你使用Windows系统，为了避免遇到各种莫名其妙的问题，请确保目录名（包括父目录）不包含中文。

将该文件夹变成管理的仓库

$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/
通过git init命令把这个目录变成Git可以管理的仓库：
瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），细心的读者可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。

所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

添加修改（文件）（一定要放到learngit目录下（子目录也行））

修改：新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

第一次修改 -> git add -> 第二次修改 -> git add -> git commit
每次修改，如果不add到暂存区，那就不会加入到commit中
用命令git add告诉Git，把文件添加到仓库
实际上就是把要提交的所有修改放到暂存区（Stage）

$ git add readme.txt

可反复多次使用，添加多个文件
执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。
第二步，用命令git commit告诉Git，把文件提交到仓库
执行git commit就可以一次性把暂存区的所有修改提交到分支。

$ git commit -m "wrote a readme file"
[master (root-commit) cb926e7] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

-m后面输入的是本次提交的说明，可以输入任意内容
每次准备提交前，先用 git status 看下，是不是都已暂存起来了，然后再运行提交命令 git commit

撤销修改

$ git checkout -- readme.txt

把readme.txt文件在工作区的修改全部撤销,让这个文件回到最近一次git commit或git add时的状态。

删除文件

在文件管理器中把没用的文件删了，或者用rm命令删了

$ rm test.txt

从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

$ git rm test.txt
$ git commit -m "remove test.txt"

版本回退

commit id

每提交一个新版本，实际上Git就会把它们自动串成一条时间线
在Git中，用HEAD表示当前版本，也就是最新的提交3628164...882e1e0
上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100

回退到上一个版本

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区

$ git reset --hard HEAD^

回退到某个版本
版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。
Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL

$ git reset --hard 3628164

查看命令历史
，以便确定要回到未来的哪个版本

$ git reflog
ea34578 HEAD@{0}: reset: moving to HEAD^
3628164 HEAD@{1}: commit: append GPL
ea34578 HEAD@{2}: commit: add distributed
cb926e7 HEAD@{3}: commit (initial): wrote a readme file

修改最后一次提交--使用当前的暂存区域快照提交
有时候我们提交完了才发现漏掉了几个文件没有加，或者提交信息写错了。想要撤消刚才的提交操作，可以使用 --amend 选项重新提交：

$ git commit --amend

如果刚才提交时忘了暂存某些修改，可以先补上暂存操作，然后再运行 --amend 提交：

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

上面的三条命令最终只是产生一个提交，第二个提交命令修正了第一个的提交内容。

其他

仓库当前的状态
如：xxx被修改过了，但还没有准备提交的修改

git status

查看不同

$ git diff readme.txt

显示从最近到最远的提交日志

$ git log

$ git log --pretty=oneline

ea34578d5496d7dd233c827ed32a8cd576c5ee85--的是commit id（版本号）--SHA1计算出来的一个非常大的数字，用十六进制表示

远程仓库

一台电脑上也是可以克隆多个版本库的，只要不在同一个目录下
一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

• 第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

$ ssh-keygen -t rsa -C "youremail@example.com"

邮件地址换成你自己的邮件地址
如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。

关联一个远程库

$ git remote add origin git@github.com:michaelliao/learngit.git

远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
本地库的内容推送到远程

$ git push -u origin master

第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令

git push origin master

克隆本地库
远程库已经准备好了
当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。

$ git clone git://github.com/schacon/grit.git

在当前目录下创建一个名为grit的目录，其中包含一个 .git 的目录，用于保存下载下来的所有版本记录，然后从中取出最新版本的文件拷贝。如果进入这个新建的 grit 目录，你会看到项目中的所有文件已经在里边了，准备好后续的开发和使用。如果希望在克隆的时候，自己定义要新建的项目目录名称，可以在上面的命令末尾指定新的名字：

$ git clone git://github.com/schacon/grit.git mygrit

唯一的差别就是，现在新建的目录成了 mygrit，其他的都和上边的一样。
Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。
在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：

$ git checkout -b dev origin/dev

分支管理

HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

123.png

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

123.png

从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针

123.png

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

123.png

Git合并分支也很快！就改改指针，工作区内容也不变！

创建dev分支，然后切换到dev分支

$ git checkout -b dev
Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

查看当前分支

$ git branch
* dev
  master

把dev分支上的工作成功合并到master上
把dev分支的工作成果合并到master分支上：

$ git merge dev
Updating d17efd8..fec145a
Fast-forward
 readme.txt |    1 +
 1 file changed, 1 insertion(+)

git merge命令用于合并指定分支到当前分支。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

删除分支

$ git branch -d dev
Deleted branch dev (was fec145a).

解决冲突

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成
master分支和feature1分支各自都分别有新的提交，变成了这样：

123.png

$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

Git告诉我们，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.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存
再提交：

$ git add readme.txt 
$ git commit -m "conflict fixed"
[master 59bc1cb] conflict fixed

123.png

$ git log --graph --pretty=oneline --abbrev-commit
*   59bc1cb conflict fixed
|\
| * 75a857c AND simple
* | 400b400 & simple
|/
* fec145a branch test

git log --graph

--no-ff方式 合并分支

使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。

$ git merge --no-ff -m "merge with no-ff" dev

123.png

123.png

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

下面我们实战一下--no-ff方式的git merge：

首先，仍然创建并切换dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'

修改readme.txt文件，并提交一个新的commit：

$ git add readme.txt 
$ git commit -m "add merge"
[dev 6224937] add merge
 1 file changed, 1 insertion(+)

现在，我们切换回master：

$ git checkout master
Switched to branch 'master'

准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 readme.txt |    1 +
 1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

合并后，我们用git log看看分支历史：

$ git log --graph --pretty=oneline --abbrev-commit
*   7825a50 merge with no-ff
|\
| * 6224937 add merge
|/
*   59bc1cb conflict fixed
...

可以看到，不使用Fast forward模式，merge后就像这样：

git-no-ff-mode

分支策略

一、主分支Master

首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发

二、开发分支Develop

主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
Git创建Develop分支的命令：

git checkout -b develop master

将Develop分支发布到Master分支的命令

　　# 切换到Master分支
　　git checkout master
　　# 对Develop分支进行合并
　　git merge --no-ff develop

临时性分支

Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
临时性分支主要有三种：
　　* 功能（feature）分支
　　* 预发布（release）分支
　　* 修补bug（fixbug）分支
这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。

功能分支

第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

123.png

#创建一个功能分支：
git checkout -b feature-x develop
#开发完成后，将功能分支合并到develop分支：
git checkout develop
git merge --no-ff feature-x
#删除feature分支：
git branch -d feature-x

预发布分支

它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试
预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。

#创建一个预发布分支：
git checkout -b release-1.2 develop
#确认没有问题后，合并到master分支：
git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点，做一个标签
git tag -a 1.2
#再合并到develop分支：
git checkout develop
git merge --no-ff release-1.2
#最后，删除预发布分支：
git branch -d release-1.2

bug分支

工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug
储藏
Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作

$ git stash
Saved working directory and index state WIP on dev: 6224937 add merge
HEAD is now at 6224937 add merge

创建分支
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
$ git checkout -b issue-101
Switched to a new branch 'issue-101'

修复bug提交代码

$ git add readme.txt 
$ git commit -m "fix bug 101"

切换分支，完成合并，删除分支

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-101
Deleted branch issue-101 (was cc17032).

查看储存的在哪里

$ git stash list
stash@{0}: WIP on dev: 6224937 add merge

工作现场还在，Git把stash内容存在某个地方了
恢复stash
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了：

$ git stash pop
# On branch dev
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   hello.py
#
# 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
#
Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash

git stash apply stash@{0}

强行删除
如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 756d4af).

多人协作

查看远程库信息

$ git remote
origin

加上 -v 选项（译注：此为 --verbose 的简写，取首字母），显示对应的克隆地址

$ git remote -v
origin  git@github.com:michaelliao/learngit.git (fetch)
origin  git@github.com:michaelliao/learngit.git (push)

推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上

$ git push origin master

推送失败
你的小伙伴的最新提交和你试图推送的提交有冲突
Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：

$ git pull
Auto-merging hello.py
CONFLICT (content): Merge conflict in hello.py
Automatic merge failed; fix conflicts and then commit the result.

但是合并有冲突，需要手动解决。解决后，提交，再push：
创建链接
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。

git branch --set-upstream branch-name origin/branch-name

标签管理

Git的标签虽然是版本库的快照

创建标签

切换到需要打标签的分支上

$ git branch
* dev
  master
$ git checkout master
Switched to branch 'master'

创建一个标签
默认标签是打在最新提交的commit上的

$ git tag v1.0

创建带有说明的标签
用-a指定标签名，-m指定说明文字：

$ git tag -a v0.1 -m "version 0.1 released" 3628164

查看所有标签
标签不是按时间顺序列出，而是按字母排序的

$ git tag
v1.0

查看标签信息

$ git show v0.9
commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Thu Aug 22 11:22:08 2013 +0800

给某次提交打标签
查找历史提交

$ git log --pretty=oneline --abbrev-commit

对add merge这次提交打标签，它对应的commit id是6224937

$ git tag v0.9 6224937

删除标签

$ git tag -d v0.1
Deleted tag 'v0.1' (was e078af9)

删除远程标签
先从本地删除

$ git tag -d v0.9
Deleted tag 'v0.9' (was 6224937)

删除一个远程标签

$ git push origin :refs/tags/v0.9
To git@github.com:michaelliao/learngit.git
 - [deleted]         v0.9

推送某个标签到远程
因为创建的标签都只存储在本地，不会自动推送到远程

推送某个标签到远程

一次性推送全部尚未推送到远程的本地标签

$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 554 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
 * [new tag]         v0.2 -> v0.2
 * [new tag]         v0.9 -> v0.9

添加忽略文件

在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。

$ cat .gitignore
*.[oa]

第一行告诉 Git 忽略所有以 .o 或 .a 结尾的文件
第二行告诉 Git 忽略所有以波浪符（~）结尾的文件
文件 .gitignore 的格式规范如下：

• 所有空行或者以注释符号 ＃ 开头的行都会被 Git 忽略。
• 可以使用标准的 glob 模式匹配。
• 匹配模式最后跟反斜杠（/）说明要忽略的是目录。
• 要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号（!）取反。
  glob 模式
  是指 shell 所使用的简化了的正则表达式。
  星号（*）匹配零个或多个任意字符；[abc] 匹配任何一个列在方括号中的字符（这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c）；问号（?）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如 [0-9] 表示匹配所有 0 到 9 的数字）。

# 此为注释 – 将被 Git 忽略
# 忽略所有 .a 结尾的文件
*.a
# 但 lib.a 除外
!lib.a
# 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO
/TODO
# 忽略 build/ 目录下的所有文件
build/
# 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
doc/*.txt
# ignore all .txt files in the doc/ directory
doc/**/*.txt

github上已经写好了，点击访问链接即可

添加被忽略的文件
可以用-f强制添加到Git：

$ git add -f App.class

检查.gitignore

$ git check-ignore -v App.class
.gitignore:3:*.class    App.class

对于任何一个文件，在 Git 内都只有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地数据库中了；已修改表示修改了某个文件，但还没有提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中。

文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。

123.png

工作目录下面的所有文件都不外乎这两种状态：已跟踪或未跟踪。
使用命令 git add 开始跟踪一个新文件（Git 只不过暂存了你运行 git add 命令时的版本）

获取帮助
想了解 Git 的各式工具该怎么用，可以阅读它们的使用帮助，方法有三：

$ git help <verb>
$ git <verb> --help
$ man git-<verb>

$ git help config

git status

On branch master 分支
nothing to commit, working directory clean 已跟踪文件在上次提交后都未被更改过
Untracked files  未跟踪文件列表
Changes to be committed  已暂存状态-已跟踪文件
Changes not staged for commit:已跟踪文件的内容发生了变化，但还没有放到暂存区 需要git add

git diff
git diff 会使用文件补丁的格式显示具体添加和删除的行。

要查看尚未暂存的文件更新了哪些部分，不加参数直接输入

$ git diff

工作目录中当前文件和暂存区域快照之间的差异，也就是修改之后还没有暂存起来的变化内容

若要看已经暂存起来的文件和上次提交时的快照之间的差异，可以用 git diff --cached 命令。

$ git diff --cached

跳过使用暂存区域
给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤

$ git commit -a -m 'added new benchmarks'

仅是从跟踪清单中删除

$ git rm --cached readme.txt

git中对文件名改名

$ git mv file_from file_to

添加远程仓库
要添加一个新的远程仓库，可以指定一个简单的名字，以便将来引用，运行 git remote add [shortname] [url]：

$ git remote
origin
$ git remote add pb git://github.com/paulboone/ticgit.git
$ git remote -v
origin  git://github.com/schacon/ticgit.git
pb  git://github.com/paulboone/ticgit.git

用字符串 pb 指代对应的仓库地址了
从远程仓库抓取数据
远程仓库中拉取所有你本地仓库中还没有的数据
运行完成后，你就可以在本地访问该远程仓库中的所有分支，将其中某个分支合并到本地，或者只是取出某个分支
fetch 命令只是将远端的数据拉到本地仓库，并不自动合并到当前工作分支，只有当你确实准备好了，才能手工合并。
如果设置了某个分支用于跟踪某个远端仓库的分支（参见下节及第三章的内容），可以使用 git pull 命令自动抓取数据下来，然后将远端分支自动合并到本地仓库中当前分支
$ git fetch [remote-name]

$ git fetch pb

推送数据到远程仓库
git push [remote-name] [branch-name]

$ git push origin master

只有在所克隆的服务器上有写权限，或者同一时刻没有其他人在推数据，这条命令才会如期完成任务。如果在你推数据前，已经有其他人推送了若干更新，那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地，合并到自己的项目中，然后才可以再次推送。
远程仓库的删除和重命名
git remote rename 命令修改某个远程仓库在本地的简称

$ git remote rename pb paul
$ git remote
origin
paul

移除远端仓库
git remote rm

$ git remote rm paul
$ git remote
origin