github分支管理

##github分支管理
在git中，每当我们commit的时候，git将会把提交的时间串成一条线，这条线就是一个分支，也就是主分支，也叫master分支（默认情况下）。严格来说，HEAD并没有指向提交，而是指向了master，master指向的提交。每次提交的时候，master就会将当前提交时间串在时间线上，并且指向当前时间点，随着不断的提交， master分支也越来越长，当我们使用git log命令的时候，查看到的就是这条时间线。
当我们创建一个新的分支，比如叫 dev，现在dev指向的提交就是master指向的提交，但是HEAD现在指向dev，现在我们再提交的时候就是提交在dev分支了，而master分支不变。当我们在dev分支上完成开发工作，检查无误后，就可以将dev分支master分支上了。
应用场景：当我们的软件开发完成1.0版本后，现在有了新的需求，要开发2.0版本。但不幸的是，在开发到一半的时候，1.0版本发现了几个bug，没办法，改吧，但是我们显然不能再现在的工程基础上修改，如果在现在工程上修改的话，1.0版本的软件将会带有部分2.0版本的特性或者功能，成了1.5版本。这时候，我们在完成1.0版本后，就可以新建一个分支，在新的分支上进行新的开发，在确认完成后，再合并到主分支。
操作如下：
###1.创建并切换到新的分支
git checkout -b dev
-b参数表示创建并切换到新的分支，相当于下面两条命令

git branch dev
git checkout dev

然后使用git branch命令查看所有的分支，在当前所在的分支上会有*提示，如下：

现在我们处于dev分支下，Test.txt文件里面没有任何内容，对Test.txt进行修改并提交。

git add Test.txt
git commit -m "branch test"

###2. 合并分支
然后切换到master分支，再去查看Test.txt文件中的内容，发现是空白的。这是因为我们提交的内容在dev分支上，master分支并没有做什么改变。效果如下图：

然后对两个分支进行合并,合并完成后删除dev分支

git merge dev
git branch -d dev

合并完成后发现Test.txt文件内容与dev分支下的完全相同

###3. 合并时的冲突
不幸的是，没有什么是一帆风顺的，合并时遇到了冲突怎么办？系统给出了这么个提示

D:\GitRepositorys [master]> git merge dev
warning: Cannot merge binary files: Test.txt (HEAD vs
Auto-merging Test.txt
CONFLICT (content): Merge conflict in Test.txt
Automatic merge failed; fix conflicts and then commit
D:\GitRepositorys [master +0 ~0 -0 !1 | +0 ~0 -0 !1]>

这个冲突貌似只能手动修改，打开冲突的文件，查看冲突提示，手动修改完成后再提交、合并
（其实我也不大懂，只是建议不要在两个分支上同时修改同一个文件）

###4 分支管理策略
####4.1 分支合并模式
通常情况下，git在合并分支的时候会用Fast forward模式，但是在这种模式下，删除分支后，会丢掉分支信息，也就是分支提交的信息，如果强制禁用Fast forward模式，git在葛冰分支的时候会生成一个新的commit，语法格式如下（将dev分支合并到master分支上）：
git merge --no-ff -m "禁用Fast forward 模式合并分支" dev
####4.2 分支策略
首先，master分支是非常稳定的，也就是仅仅用来发布新的版本。
其次，从master分支上创建一个新的分支（dev），每个开发人员都有自己的分支（从dev分支上创建的），推送代码时只要将自己的分支和dev分支合并就可以了，
最后，当药发布新版本时，只需要将dev分支合并到master分支就可以了
####4.3 bug分支
当你正在进行开发时，突然间发现了以前的一个bug，需要立刻修复，但是你现在的开发工作还没有完成，没有办法提交，git提供了一个stash功能，可以把当前场景保存起来，等以后可以恢复现场：git stash，现在用git status查看工作区，是干净的了，可以创建一个新的分支（首先要确定从哪个分支上修复bug），修复完成后，合并并删除bug分支。
现在我们需要恢复现场，使用git stash list命令来查看保存了哪些现场，恢复现场有两种方式，一是用git stash apply stash@{NUM} 或者是用git stash pop，区别是前者不会删除stash，恢复现场后需要收到执行 git stash drop来删除。当然，也可以多次stash然后使用git stash apply stash@{num}来恢复指定的现场。
###5. 多人协作
####5.1 克隆仓库
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

要查看远程库的信息，用git remote：

$ git remote
origin

或者，用git remote -v显示更详细的信息：

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

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。
####5.2 推送分支
推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
$ git push origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev
####5.3 抓取分支
多人协作时，大家都会往master和dev分支上推送各自的修改。当我们从远程仓库克隆的时候，我们只能看到本地master分支，如果我们要在其他分支上开发，就必须创建origin的其他分支到本地，或者说建立远程分支和本地分支的关联:
git checkout -b dev origin/dev,然后，我们就可以在dev分支上继续修改，然后将修改后的项目推送到远程

6. 标签管理

####6.1 创建标签
首先切换到需要打标签的分支上，git checkout branch-name,
然后使用命令git tag <name>就可以了，默认标签是打在最新提交上的，如果我们想要打在以前的提交上，可以使用git log查看以前提交的commit id，然后使用git tag <name> <commit id>就可以了。可以使用命令git tag查看标签，但是标签不是按照时间顺序排序的，而是按照字母顺序排序。在打标签的时候可以带有说明，语法格式如下：
git tag -a <tag-name> -m "comment" <commit id>
使用命令git show <tag-name>可以查看详细信息。

6.2 删除标签

如果标签打错了，可以使用git tag -d <tag-name>来删除指定的标签，默认情况下，标签不会自动推送到远程。如果想把某个标签推送到远程，可以使用git push origin <tag-name>，或者一次性推送所有本地的标签:git push origin --tags,如果标签已经推送的远程仓库，想要删除远程仓库的标签需要如下两步:
首先删除本地标签 git tag -d <tag-name>
然后从远程删除 git push origin :refs/tags/<tag-name>