Git----分支管理

Git

今天我们介绍下我们经常使用的GIT代码管理工具，相信大家对这个的使用以及好处都已经很熟悉了吧，那么今天我就说下我觉得Git中最显著的一个优点——版本的分支和合并十分方便。

讲到GIT，那么我们就不得不说下另一个代码管理工具SVN了SVN
那么Git存储和SVN存储在版本控制中的存储方式版本信息的差异？

Git关心的是文件的整体是否发生变化，而SVN则关心的是文件内容的巨日差异！SVN每次记录的是有哪些文件进行了修改，以及修改了哪些行的哪些内容：

比如版本二记录的是文件A以及文件C的变化，而版本三中仅仅记录了文件C的变化。但是GIT并不保存这些前后变化的差异数据啊，而是保存整个当前工作区间的所有文件，又叫快照，有变化的文件保存，没变化的文件就不保存，而是对上一次保存的快照做一个链接
因为不同的保存方式，所以Git和SVN在切换分支的时候Git的速度快很多

Git每次commit时候，在仓库中的数据结构

每次commit的时候commit中有一个tree对象，tree对象则是记录快照索引的目录，里面存着多个blob对象，每一个blob对象存储的就是文件的快照内容。

什么是分支？

刚才我们已经介绍了快照（整个当前的工作空间暂存区（暂存区）的所有文件），那么每个快照（版本库）又是怎样的组合到一起的呢？

Git会将这些快照串成一条条的时间线，而这些时间线就是我们的分支如果我们不创建分支，那么每次commit生成的快照都会被串到一条线上，而这条时间线就叫做Master分支，除了这个Master分支我们还要知道一个东西就是HEAD指针，这个指针正是指向正在工作的本地分支，版本回退就是修改的HEAD指针的指向而已

而传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而GIT则只生成一个指向当前版本（“快照”）的指针，因此十分方便快捷。

为什么要创建其他分支呢？

有时候就在想为什么要创建分支呢，已经有一个master分支了，我们每次push到远程服务器，每个人pull一下服务器上的代码不就好了，再建分支好像没有必要吧。
其实这样做并不好，

1. 一般master上放的是大版本的改动，develop上是小细节的改动，如果只有一条master分支，就以为着分支线会非常非常的倡， 曾经在上线了一个app，之后一直在修改小细节，但是一直在master分支上，突然有一天用户发邮件说有bug，就会发现之前的1.0本已经很早很早了，差点没了。
2. 
   
   1. 效率问题，如果每次提交出现了冲突，而这个冲突很难解决，如果只有一个master分支就会卡在这里，就无法向后面开发了。

当然如果使用不当就会留下一个枝节蔓生的版本库，到处都十分之，完全看不出来主干发展的脉络，这就意味着我们要合理使用GIT分支.
我们从分支种类来进行阐述吧

1. 一. 主分支Master
2. 二. 开发分支develop
3. 三. 临时性分支
   3.1 四. 功能分支
   3.2 五. 预发布分支
   3.3 六. Bug分支

一．主分支Master

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

二.开发分支Develop

主分支只用来发布重大版本，比如MyApp1.0，2.0。
日常开发应该在另一条分支上完成。我们把开发用的分支叫做Develop

我们的日常开发提交应该在这个分支上。如果想正式对外发布，就在Master分支上，对Develop分支进行合并。
Git创建Develop分支的命令：

    git branch develop master
    git checkout develop 

将Develop分支合并到Master分支的命令

git merge --no-ff develop 

这里就要解释下了，合并指令的–no-ff参数是什么意思了，ff就是fast-farward。默认情况下，Git执行“快进式合并”（fast-farward merge），就是直接将Master分支指向Develop分支，的确很快，因为只是变更了一个指针指向

使用–no-ff参数后，会执行正常合并，在Master分支上新生成一个节点，

那么通过这两个图，我们很明显就知道了为什么要使用–no-ff合并分支了，因为快进式合并，无法看出曾经合并过，对于版本的演进主线很不明了。而第二种正常合并就明显可以看出合并记录，结构清晰。

三.临时性分支

Master和Develop是版本库的两条主要分支，前者用于正式发布，后者用于日常开发，除了这两种分支外还有一些临时性分支，用于应对一些特定目的的版本开发。

临时性分支主要有三种

• 功能（feature）分支
• 预发布（release）分支
• 修补bug（fixbug）分支

这三种分支属于临时需要的，使用完之后应该删除，使得代码库的常设分支始终只有Master和Develop分支

四. 功能分支

功能分支就是为了开发某一功能而创建的分支，它从Develop上面分出来，开发完成后，在合并入Develop，删除功能分支

创建一个功能分支

git branch feature develop

git checkout feature

开发完成后，将功能分支合并到develop分支：

git checkout develop

git merge --no-ff feature

删除feature分支

git branch -d feature

五.预发布分支

它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。

预发布分支是从Develop上分支出来的，预发布结束后，必须合并到Develop和Master分支。
创建一个预发布分支：

git checkout -b release-1.0 develop

确认版本没有问题后，合并到master分支上：

git checkout master

git merge --no-ff release-1.0

#对合并生成的新节点做一个标签
git tag -a 1.0

再合并到develop分支上

git checkout develop

git merge --no-ff release-1.0

最后，删除预发布分支：

git branch -d release-1.0

六.修补bug分支

软件开发中，bug就像是家常便饭。有了bug就需要修复。在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除，

当你接到一个bug修复的任务时，我们会想到创建一个分支来修复它，但是，当前我们正在develop上进行工作还没有提交。

我们通过 git status 会发现工作区有待提交的内容，这时我们要么提交一个还未完成的任务，当然还有一种方法，Git提供了一个stash 功能，可以将当前工作现场储藏起来，等以后恢复现场后继续工作，

git stash

git status

这时我们查看工作区，就是干净的。

当我们在bug分支工作完之后。将其合并到master分支，最后删除bug分支。切换至develop分支

git stash list


//
git stash reply stash@{0}

git stash drop

//或者
git stash pop

它们的意思是把stash保存的内容恢复并且删除stash内容

这样我们就回到了develop分支上了。

最后

记录些常用的命令

• git init 初始化一个仓库

• git remote add origin git@git.oschina.net:xz878/XiYouFastPass.git

• git remote add origin https://github.com/xiyouWyz/EveryNews.git

• git pull origin master 第一次git push -u origin master 之后git push origin
  master

• git add . 将当前目录的所有文件添加至索引库中

• git commit -m “2016-6-1”

• git status列出当前目录没有被git管理的文件和被git管理且被修改但还未提交的文件

• git branch develop master在master创建分支

• git checkout develop 切换到develop分支

• git checkout -b release-1.0 develop在develop分支上创建release分支并切换

• git checkout develop；git merge –no-ff release-1.0
  将release-1.0分支合并到develop分支

• git reflog 查看历史提交，
  可以查看所有分支的所有操作记录（包括（包括commit和reset的操作），包括已经被删除的commit记录，git log则不能察看已经删除了的commit记录

• git reset –hard 63ee781 恢复至版本号为63ee781的版本

• git log –graph –pretty=oneline –abbrev-commit 查看分支历史