1 分支简介
让我们来看一个简单的分支新建与分支合并的例子，实际工作中你可能会用到类似的工作流。 你将经历如下步骤：
- 开发某个网站。
- 为实现某个新的需求，创建一个分支。
- 在这个分支上开展工作。
正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理： - 切换到你的线上分支（production branch）。
- 为这个紧急任务新建一个分支，并在其中修复它。
- 在测试通过之后，切换回线上分支，然后合并这个修补分支，最后将改动推送到线上分支。
- 切换回你最初工作的分支上，继续工作。
git checkout -b iss53
iss55有了新的提交，HEAD指针向前推进
紧急上线，回到master，HEAD指向master，新建hotfix分支，HEAD指向hotfix
$ git checkout master
$ git checkout -b hotfix
hotfix上线之后，需要将hotfix分支同步到master，此时需要merge，由于当前 master 分支所指向的提交是你当前提交（有关 hotfix 的提交）的直接上游，所以 Git 只是简单的将指针向前移动。
$ git checkout master
$ git merge hotfix
关于这个紧急问题的解决方案发布之后，你准备回到被打断之前时的工作中。 然而，你应该先删除 hotfix 分支
$ git branch -d hotfix
回到iss55继续工作
$ git checkout iss53
如果你需要拉取 hotfix 所做的修改，你可以使用 git merge master 命令将 master 分支合并入 iss53 分支，或者你也可以等到 iss53 分支完成其使命，再将其合并回 master 分支。
$ git checkout master
$ git merge iss53
这和你之前合并 hotfix 分支的时候看起来有一点不一样。 在这种情况下，你的开发历史从一个更早的地方开始分叉开来（diverged）。 因为，master 分支所在提交并不是 iss53 分支所在提交的直接祖先，Git 不得不做一些额外的工作。 出现这种情况的时候，Git 会使用两个分支的末端所指的快照（C4 和 C5）以及这两个分支的工作祖先（C2），做一个简单的三方合并。
和之前将分支指针向前推进所不同的是，Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。 这个被称作一次合并提交，
$ git branch -d iss53
如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们。 如果你对 #53 问题的修改和有关 hotfix 的修改都涉及到同一个文件的同一处，在合并它们的时候就会产生合并冲突，比如你在hotfix和iss55都修改index.html文件
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
这个时候可以查看下git status
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")
打开index.html
<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
上述的冲突解决方案仅保留了其中一个分支的修改，并且 <<<<<<< , ======= , 和 >>>>>>> 这些行被完全删除了。 在你解决了所有文件里的冲突之后，对每个文件使用 git add 命令来将其标记为冲突已解决。
如果你对结果感到满意，并且确定之前有冲突的的文件都已经暂存了，这时你可以输入 git commit 来完成合并提交
git add .
git commit -m "xxx"
上述解决冲突结果看起来就像一个新的"合并的提交"，如果你想让"mywork"分支历史看起来像没有经过任何合并一样，你也许可以用 git rebase:
git checkout iss53
git rebase origin
这些命令会把你的"iss53"分支里的每个提交(commit)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 为最新的"origin"分支，最后把保存的这些补丁应用到"iss53"分支上。
2 分支管理
$ git branch
master
* release/20171109 //*指当前HEAD指向的位置 如果此时有提交，指针会向前移动
如果需要查看每一个分支的最后一次提交，可以运行 git branch -v 命令
$ git branch -v
master 5254935 Merge branch 'release/20171026' into 'master'
* release/20171109 3c887ce 账号设置企业联想 2、修改变更鼠标放到尾部
$ git branch -m 当前分支 新分支 //从当前分支拉新分支
3 远程分支
远程引用是对远程仓库的引用（指针），你可以通过 git ls-remote (remote) 来显式地获得远程引用的完整列表
git ls-remote
假设你的网络里有一个在 git.ourcompany.com 的 Git 服务器。 如果你从这里克隆，Git 的 clone 命令会为你自动将其命名为 origin，拉取它的所有数据
你在本地的 master 分支做了一些工作，然而在同一时间，其他人推送提交到 git.ourcompany.com 并更新了它的 master 分支，那么你的提交历史将向不同的方向前进。 也许，只要你不与 origin 服务器连接，你的 origin/master 指针就不会移动。
运行 git fetch origin 命令。 这个命令查找 “origin” 是哪一个服务器（在本例中，它是 git.ourcompany.com），从中抓取本地没有的数据，并且更新本地数据库，移动 origin/master 指针指向新的、更新后的位置。但是远程master代码不会和本地master进行合并，必须手动merge，git merge origin/master，可以用git pull自动合并
删除远程分支
$ git push origin --delete serverfix