1、github官网注册账号，下载gitbash，完成基本配置，推荐开源中国上的一篇博客：简单使用Git和Github来管理自己的代码和读书笔记
2、基础阶段常用操作：
知乎上关于git三个区解释如下：
工作区(working diretory) 用于修改文件 缓存区(stage) 是用来暂时存放工作区中修改的内容 提交历史（commit history） 提交代码的历史记录
| 作用 | 方法 |
|---|---|
| 在当前目录新建一个Git代码库 | $git init |
| 下载一个项目和它的整个代码历史 | $git clone [url] |
| 查看用户名 | $git config user.name |
| 查看用户邮箱 | $git config user.email |
| 重设用户名 | $git config --global user.name “用户名” |
| 重设邮箱 | $git config --global user.email “邮箱名” |
| 添加指定文件到暂存区 | $git add [file1] [file2] … |
| 添加当前目录的所有文件到暂存区 | $git add . |
| 删除工作区文件，并且将这次删除放入暂存区 | $git rm [file1] [file2] … |
| 提交暂存区到仓库区 | $git commit -m [message] |
下面详细叙述一些命令
1、vim命令的使用
一、vim 有两种工作模式：
1.命令模式：接受、执行 vim操作命令的模式，打开文件后的默认模式；
2.编辑模式：对打开的文件内容进行 增、删、改 操作的模式；
3.在编辑模式下按下ESC键，回退到命令模式；在命令模式下按i，进入编辑模式
二、创建、打开文件：
1.输入 touch 文件名 ，可创建文件。
2.使用 vim 加文件路径（或文件名）的模式打开文件，如果文件存在则打开现有文件，如果文件不存在则新建文件。
3.键盘输入字母i进入插入编辑模式。
三、保存文件：
1.在编辑模式下编辑文件
2.按下ESC键，退出编辑模式，切换到命令模式。
3.在命令模式下键入"ZZ"或者":wq"保存修改并且退出 vim。
4.如果只想保存文件，则键入":w"，回车后底行会提示写入操作结果，并保持停留在命令模式。
四、放弃所有文件修改：
1.放弃所有文件修改：按下ESC键进入命令模式，键入":q!“回车后放弃修改并退出vim。
2.放弃所有文件修改，但不退出 vi，即回退到文件打开后最后一次保存操作的状态，继续进行文件操作：按下ESC键进入命令模式，键入”:e!"，回车后回到命令模式。
五、查看文件内容：
在git窗口，输入命令：cat 文件名
六、创建文件夹
在git窗口，输入命令：touch 文件夹名
2、git status
注意：git status -s只是简短的输出结果，与git status无本质区别
git status 以查看在你上次提交之后是否有修改
使用vim命令对已有文件插入等操作后，在执行git status
基本操作如下
1、执行 $vim git2.txt
出现编辑页面，按照vim的基本操作操作
执行 $git status
结果：
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: git.txt
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: git2.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
git
2、执行 $git status -s
结果：
$ git status -s
M git.txt（之前执行过的）
M git2.txt
?? git
3、执行：
$git add git2.txt
$git status
结果：
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: git.txt
modified: git2.txt //出现了
Untracked files:
(use "git add <file>..." to include in what will be committed)
git
4、当全部add到暂存区后在执行git status -s
结果：//"AM" 状态的意思是，这个文件在我们将它添加到缓存（暂存区）之后又有改动
A git
M git.txt
M git2.txt
3、git diff
执行 git diff 来查看执行 git status 的结果的详细信息。
git diff 命令显示已写入缓存与已修改但尚未写入缓存的改动的区别。git diff 有两个主要的应用场景。
尚未缓存的改动：git diff
查看已缓存的改动： git diff --cached（add命令之后）
查看已缓存的与未缓存的所有改动：git diff HEAD
显示摘要而非整个 diff：git diff --stat
实例：
$ git diff --cached
diff --git a/git b/git
new file mode 100644
index 0000000..eac2252
--- /dev/null
+++ b/git
@@ -0,0 +1,2 @@
+<D6><B4><D0><D0><C1><CB><B2><E5><C8><EB><B2><D9><D7><F7>ZZ
+HELLO
diff --git a/git.txt b/git.txt
index 5255b58..e74700d 100644
--- a/git.txt
+++ b/git.txt
@@ -1 +1,2 @@
-<B3><CC><D0><F2>
\ No newline at end of file
+<B3><CC><D0><F2>
+git status testings
diff --git a/git2.txt b/git2.txt
index 5cfb0d7..d2deb43 100644
--- a/git2.txt
+++ b/git2.txt
@@ -1 +1,2 @@
4、git diff
git reset HEAD 命令用于取消已缓存的内容
示例：
$ git status -s
M git.txt
M git2.txt
Administrator@965CKTUF3BYFX7F MINGW64 /e/Git/GitTest (master)
$ git reset HEAD -- git2.txt
Unstaged changes after reset:
M git2.txt
Administrator@965CKTUF3BYFX7F MINGW64 /e/Git/GitTest (master)
$ git status -s
M git.txt
M git2.txt
5、git rm
如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 Changes not staged for commit 的提示。要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除，然后提交。可以用以下命令完成此项工作git rm <file>
如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 git rm -f <file>
如果把文件从暂存区域移除，但仍然希望保留在当前工作目录中，换句话说，仅是从跟踪清单中删除，使用 --cached 选项即可git rm --cached <file>
如我们删除 hello.php文件：
$ git rm hello.php
rm 'hello.php'
$ ls
README
不从工作区中删除文件：
rm 'README'
$ ls
README
可以递归删除，即如果后面跟的是一个目录做为参数，则会递归删除整个目录中的所有子目录和文件：git rm –r *
进入某个目录中，执行此语句，会删除该目录下的所有文件和子目录。git mv命令用于移动或重命名一个文件、目录、软连接。我们先把刚移除的 README 添加回来：$ git add README
然后对其重名:
$ git mv README README.md
$ ls
README.md
git branch 分支
以下内容摘自博客 git branch 分支
Git 保存的不是文件的变化或者差异，而是一系列不同时刻的文件快照。在进行提交操作时，Git 会保存一个提交对象，该提交对象会包含一个指向暂存内容快照的指针。 但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象，而由多个分支合并产生的提交对象有多个父对象。
Git 的分支，其实分支上仅仅是指向提交对象的可变指针。 Git的默认分支名字是 master ，在多次提交操作之后，你其实已经有一个指向最后那个提交对象的 master 分支。它会在每次的提交操作中自动向前移动。
注意： Git的 “master” 分支并不是一个特殊分支。它就跟其他分支完全没有区别。之所以几乎每一个仓库都有 master 分支，是因为 git init 命令默认创建它，并且大多数人都懒得去改动它。
1、创建分支
git branch 分支名
例如：git branch gittest1
执行 $git log --oneline --decorate
结果：
$ git log --oneline --decorate
4674fac (HEAD -> master, gittest1) all reset
b5aecaa (origin/master) Third
f9ddd86 Second submit
aea39a3 first
192f45f Initial commit
对上述结果作如下图形解释：
执行过git branch gittest1后会在当前所在的提交对象上创建一个指针
那么，Git 是如何知道当前在哪一个分支上呢？ 也很简单，它有一个名为 HEAD 的特殊指针。 请注意它和许多其它版本控制系统（如 Subversion 或 CVS）里的 HEAD 概念完全不同。 在 Git 中，它是一个指针，指向当前所在的本地分支（将 HEAD 想象为当前分支的别名）。 在本例中，你仍然在 master 分支上。 因为 git branch 命令仅仅创建一个新分支，并不会自动切换到新分支中去。
如上图所示，当前 “master” 和 “testing” 分支均指向校验和以 4674fac 开头的提交对象
2、分支切换
执行 $git chechout 分支名
如：git checkout gittest1
结果为：
$ git checkout gittest1
Switched to branch 'gittest1'
M test.txt
现在对gittest1分支进行操作
执行：$vim test.txt，对test.txt进行更改
接着执行：$git commit -a -m 'made a change'
结果：
$ git commit -a -m 'made a change'
[gittest1 6aee2ca] made a change
1 file changed, 3 insertions(+)
再执行：$git log --oneline --decorate
结果为：
6aee2ca (HEAD -> gittest1) made a change
4674fac (master) all reset
b5aecaa (origin/master) Third
f9ddd86 Second submit
aea39a3 first
192f45f Initial commit
发现gittest1分支向右移动，而master分支没动
切换到master执行$git checkout master 这条命令做了两件事。 一是使 HEAD 指回 master 分支，二是将工作目录恢复成 master 分支所指向的快照内容。 也就是说，你现在做修改的话，项目将始于一个较旧的版本。 本质上来讲，这就是忽略 gittest1 分支所做的修改，以便于向另一个方向进行开发。
注意：分支切换会改变你工作目录中的文件
在切换分支时，一定要注意你工作目录里的文件会被改变。 如果是切换到一个较旧的分支，你的工作目录会恢复到该分支最后一次提交时的样子。 如果 Git 不能干净利落地完成这个任务，它将禁止切换分支。
下面在在master分支上做如下事情
执行 $vim git.txt
接着执行：$git commit -a -m 'make all chages'
结果为：
$ git commit -a -m 'make all changes'
[master ff42feb] make all changes
1 file changed, 1 insertion(+)
接着执行查看操作：
$ git log --oneline --decorate
ff42feb (HEAD -> master) make all changes//发现master也已经向右移动，具体结果如下图所示
4674fac all reset
b5aecaa (origin/master) Third
f9ddd86 Second submit
aea39a3 first
192f45f Initial commit
如图：
$ git log --oneline --decorate --graph --all
结果如下，与上图一致。
$ git log --oneline --decorate --graph --all
* ff42feb (HEAD -> master) make all changes
| * 6aee2ca (gittest1) made a change
|/
* 4674fac all reset
* b5aecaa (origin/master) Third
* f9ddd86 Second submit
* aea39a3 first
* 192f45f Initial commit
**关于分支创建的一些叙述：**由于 Git 的分支实质上仅是包含所指对象校验和（长度为 40 的 SHA-1 值字符串）的文件，所以它的创建和销毁都异常高效。 创建一个新分支就像是往一个文件中写入 41 个字节（40 个字符和 1 个换行符）。这与过去大多数版本控制系统形成了鲜明的对比，它们在创建分支时，将所有的项目文件都复制一遍，并保存到一个特定的目录。 完成这样繁琐的过程通常需要好几秒钟，有时甚至需要好几分钟。所需时间的长短，完全取决于项目的规模。而在 Git 中，任何规模的项目都能在瞬间创建新分支。 同时，由于每次提交都会记录父对象，所以寻找恰当的合并基础（译注：即共同祖先）也是同样的简单和高效。 这些高效的特性使得 Git 鼓励开发人员频繁地创建和使用分支。
创建分支的同时更换到此分支可执行 git checkout -b 分支名，如：git checkout -b test。
**注意：**当项目在某点出现问题时，就可以新建分支并切换到此分支上进行修复。当问题修复后，就需要将分支合并，下面介绍分支的合并
3、分支合并
分支合并，首先应该切换到 master 分支，但是，在切换之前，要留意你的工作目录和暂存区里那些还没有被提交的修改，它可能会和你即将检出的分支产生冲突从而阻止 Git 切换到该分支。 最好的方法是，在你切换分支之前，保持好一个干净的状态。 有一些方法可以绕过这个问题（即，保存进度（stashing） 和 修补提交（commit amending））。假设可以切换回 master 分支
执行:
$git checkout master
接着就可以合并分支了，执行
git merge 刚才用于修复bug的分支
如：git merge test
执行上述命令后 Git 会为你完成合并工作，Git 将此次合并的结果做一个新的快照并且自动创建一个新的提交指向它，一切就是这么简单。
4、遇到冲突时的分支合并
有时候合并操作并不会如此顺利。如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们。 如果你在对 某个 问题的修改和在 master 的修改都涉及到同一个文件的同一处，在合并它们的时候就会产生合并冲突：
$ git merge issue10
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并（unmerged）状态的文件。
任何因包含合并冲突而有待解决的文件，都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记，这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段，看起来像下面这个样子：
<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> issue10:index.html
这表示 HEAD 所指示的版本（也就是你的 master 分支所在的位置，因为你在运行 merge 命令的时候已经检出到了这个分支）在这个区段的上半部分（======= 的上半部分），而刚才问题的分支所指示的版本在 ======= 的下半部分。 为了解决冲突，你必须选择使用由 ======= 分割的两部分中的一个，或者你也可以自行合并这些内容。 例如，你可以通过把这段内容换成下面的样子来解决冲突：
<div id="footer">
please contact us at email.support@github.com
</div>
上述的冲突解决方案仅保留了其中一个分支的修改，并且 <<<<<<< , ======= , 和 >>>>>>> 这些行被完全删除了。 在你解决了所有文件里的冲突之后，对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件，Git 就会将它们标记为冲突已解决。
你可以再次运行 git status 来确认所有的合并冲突都已被解决，如果你对结果感到满意，并且确定之前有冲突的的文件都已经暂存了，这时你可以输入 git commit 来完成合并提交。
5、删除分支
直接执行：git branch -d 分支名
6、分支管理
git branch 命令不只是可以创建与删除分支。 如果不加任何参数运行它，会得到当前所有分支的一个列表：
$ git branch
gittest1
* master
注意 master 分支前的 * 字符：它代表现在检出的那一个分支（也就是说，当前 HEAD 指针所指向的分支）。 这意味着如果在这时候提交，master 分支将会随着新的工作向前移动。 如果需要查看每一个分支的最后一次提交，可以运行 git branch -v 命令：
$ git branch -v
gittest1 6aee2ca made a change
* master ff42feb make all changes
–merged 与 --no-merged 这两个有用的选项可以过滤这个列表中已经合并或尚未合并到当前分支的分支
$ git branch --merged
* master
Administrator@965CKTUF3BYFX7F MINGW64 /e/Git/GitTest (master)
$ git branch --no-merged
gittest1
当包含了还未合并的工作的分支，尝试使用 git branch -d 命令删除它时会失败，如果真的想要删除分支并丢掉那些工作，可以使用 -D 选项强制删除它。
分支开发工作流
由于分支管理的便捷，因此衍生出一些典型的工作模式，可根据项目实际情况选择使用。
1、长期分支
因为 Git 使用简单的三方合并，所以就算在一段较长的时间内，反复把一个分支合并入另一个分支，也不是什么难事。 也就是说，在整个项目开发周期的不同阶段，你可以同时拥有多个开放的分支；你可以定期地把某些特性分支合并入其他分支中。
许多使用 Git 的开发者都喜欢使用这种方式来工作，比如只在 master 分支上保留完全稳定的代码——有可能仅仅是已经发布或即将发布的代码。 他们还有一些名为 develop 或者 next 的平行分支，被用来做后续开发或者测试稳定性——这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入 master 分支了。 这样，在确保这些已完成的特性分支（短期分支，比如之前的 issue10 分支）能够通过所有测试，并且不会引入更多 bug 之后，就可以合并入主干分支中，等待下一次的发布。
一些大型项目还有一个 proposed（建议） 或 pu: proposed updates（建议更新）分支，它可能因包含一些不成熟的内容而不能进入 next 或者 master 分支。 这么做的目的是使你的分支具有不同级别的稳定性；当它们具有一定程度的稳定性后，再把它们合并入具有更高级别稳定性的分支中。 再次强调一下，使用多个长期分支的方法并非必要，但是这么做通常很有帮助，尤其是当你在一个非常庞大或者复杂的项目中工作时。
2、特性分支
特性分支对任何规模的项目都适用。 特性分支是一种短期分支，它被用来实现单一特性或其相关工作。 也许你从来没有在其他的版本控制系统（VCS）上这么做过，因为在那些版本控制系统中创建和合并分支通常很费劲。 然而，在 Git 中一天之内多次创建、使用、合并、删除分支都很常见。
你在自己的特性分支（如 iss53 和 hotfix 分支）中提交了一些更新，并且在它们合并入主干分支之后，你又删除了它们。 这项技术能使你快速并且完整地进行上下文切换（context-switch）——因为你的工作被分散到不同的流水线中，在不同的流水线中每个分支都仅与其目标特性相关，因此，在做代码审查之类的工作的时候就能更加容易地看出你做了哪些改动。 你可以把做出的改动在特性分支中保留几分钟、几天甚至几个月，等它们成熟之后再合并，而不用在乎它们建立的顺序或工作进度。
请牢记，当你做这么多操作的时候，这些分支全部都存于本地。 当你新建和合并分支的时候，所有这一切都只发生在你本地的 Git 版本库中 —— 没有与服务器发生交互。
3、远程分支
远程引用是对远程仓库的引用（指针），包括分支、标签等等。 可通过 git ls-remote (remote) 来显式地获得远程引用的完整列表，或者通过 git remote show (remote) 获得远程分支的更多信息。 然而，一个更常见的做法是利用远程跟踪分支。
远程跟踪分支是远程分支状态的引用。 它们是你不能移动的本地引用，当你做任何网络通信操作时，它们会自动移动。 远程跟踪分支像是你上次连接到远程仓库时，那些分支所处状态的书签。
它们以 (remote)/(branch) 形式命名。假设你的网络里有一个在 git.ourcompany.com 的 Git 服务器。 如果你从这里克隆，Git 的 clone 命令会为你自动将其命名为 origin，拉取它的所有数据，创建一个指向它的 master 分支的指针，并且在本地将其命名为 origin/master。 Git 也会给你一个与 origin 的 master 分支在指向同一个地方的本地 master 分支，这样你就有工作的基础。
注意：“origin” 并无特殊含义
远程仓库名字 “origin” 与分支名字 “master” 一样，在 Git 中并没有任何特别的含义一样。 同时 “master” 是当你运行 git init 时默认的起始分支名字，原因仅仅是它的广泛使用，“origin” 是当你运行 git clone 时默认的远程仓库名字。 如果你运行 git clone -o booyah，那么你默认的远程分支名字将会是 booyah/master。
4、推送分支到远程服务器
当你想要公开分享一个分支时，需要将其推送到有写入权限的远程仓库上。 本地的分支并不会自动与远程仓库同步 - 你必须显式地推送想要分享的分支。 这样，你就可以把不愿意分享的内容放到私人分支上，而将需要和别人协作的内容推送到公开分支。
如果希望和别人一起在名为 serverfix 的分支上工作，你可以像推送第一个分支那样推送它。 运行 git push (remote) (branch):
$ git push origin serverfix
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
To https://github.com/schacon/simplegit
* [new branch] serverfix -> serverfix
Git 自动将 serverfix 分支名字展开为 refs/heads/serverfix:refs/heads/serverfix，那意味着，“推送本地的 serverfix 分支来更新远程仓库上的 serverfix 分支。”
下一次其他协作者从服务器上抓取数据时，他们会在本地生成一个远程分支 origin/serverfix，指向服务器的 serverfix 分支的引用：
$ git fetch origin
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/schacon/simplegit
* [new branch] serverfix -> origin/serverfix
要特别注意的一点是当抓取到新的远程跟踪分支时，本地不会自动生成一份可编辑的副本（拷贝）。 换一句话说，这种情况下，不会有一个新的 serverfix 分支 - 只有一个不可以修改的 origin/serverfix 指针。
可以运行 git merge origin/serverfix 将这些工作合并到当前所在的分支。 如果想要在自己的 serverfix 分支上工作，可以将其建立在远程跟踪分支之上：
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'
这会给你一个用于工作的本地分支，并且起点位于 origin/serverfix。
5、跟踪分支
从一个远程跟踪分支检出一个本地分支会自动创建一个叫做 “跟踪分支”（有时候也叫做 “上游分支”）。 跟踪分支是与远程分支有直接关系的本地分支。 如果在一个跟踪分支上输入 git pull，Git 能自动地识别去哪个服务器上抓取、合并到哪个分支。
当克隆一个仓库时，它通常会自动地创建一个跟踪 origin/master 的 master 分支。 然而，如果你愿意的话可以设置其他的跟踪分支 - 其他远程仓库上的跟踪分支，或者不跟踪 master 分支。 可运行 git checkout -b [branch] [remotename]/[branch]。 这是一个十分常用的操作所以 Git 提供了 –track 快捷方式：
$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'
将本地分支与远程分支设置为不同名字:
$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'
现在，本地分支 sf 会自动从 origin/serverfix 拉取。
设置已有的本地分支跟踪一个刚刚拉取下来的远程分支，或者想要修改正在跟踪的上游分支，你可以在任意时间使用 -u 或 –set-upstream-to 选项运行 git branch 来显式地设置。
$ git branch -u origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
查看设置的所有跟踪分支，可以使用 git branch 的 -vv 选项。 这会将所有的本地分支列出来并且包含更多的信息，如每一个分支正在跟踪哪个远程分支与本地分支是否是领先、落后或是都有。
$ git branch -vv
iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets
master 1ae2a45 [origin/master] deploying index fix
* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it
testing 5ea463a trying something new
这里可以看到 iss53 分支正在跟踪 origin/iss53 并且 “ahead” 是 2，意味着本地有两个提交还没有推送到服务器上。 也能看到 master 分支正在跟踪 origin/master 分支并且是最新的。 接下来可以看到 serverfix 分支正在跟踪 teamone 服务器上的 server-fix-good 分支并且领先 2 落后 1，意味着服务器上有一次提交还没有合并入同时本地有三次提交还没有推送。 最后看到 testing 分支并没有跟踪任何远程分支。
需要重点注意的一点是这些数字的值来自于你从每个服务器上最后一次抓取的数据。 这个命令并没有连接服务器，它只会告诉你关于本地缓存的服务器数据。 如果想要统计最新的领先与落后数字，需要在运行此命令前抓取所有的远程仓库。 可以像这样做：$ git fetch –all; git branch -vv
6、拉取
当 git fetch 命令从服务器上抓取本地没有的数据时，它并不会修改工作目录中的内容。 它只会获取数据然后让你自己合并。 然而，有一个命令叫作 git pull 在大多数情况下它的含义是一个 git fetch 紧接着一个 git merge 命令。 如果有一个像之前章节中演示的设置好的跟踪分支，不管它是显式地设置还是通过 clone 或 checkout 命令为你创建的，git pull 都会查找当前分支所跟踪的服务器与分支，从服务器上抓取数据然后尝试合并入那个远程分支。
由于 git pull 的魔法经常令人困惑所以通常单独显式地使用 fetch 与 merge 命令会更好一些。
7、删除远程分支
假设你已经通过远程分支做完所有的工作了 - 也就是说你和你的协作者已经完成了一个特性并且将其合并到了远程仓库的 master 分支（或任何其他稳定代码分支）。 可以运行带有 –delete 选项的 git push 命令来删除一个远程分支。 如果想要从服务器上删除 serverfix 分支，运行下面的命令：
$ git push origin --delete serverfix
To https://github.com/schacon/simplegit
- [deleted] serverfix
基本上这个命令做的只是从服务器上移除这个指针。 Git 服务器通常会保留数据一段时间直到垃圾回收运行，所以如果不小心删除掉了，通常是很容易恢复的。
至此，你现在应该能自如地创建并切换至新分支、在不同分支之间切换以及合并本地分支，你现在应该也能通过推送你的分支至共享服务以分享它们、使用共享分支与他人协作。