Git的分支管理

0.引言

本文参考最后的几篇文章，将git的分支管理整理以下。学习git的分支管理将能够版本进行灵活有效的控制。

1.如何创建与合并分支

1.1分支的新建与合并指令

新建分支 newBranch，并进入新分支：

$ git checkout -b newBranch　

至关于：

$ git branch newBranch
$ git checkout newBranch

合并分支 mergeBranch，例如要把mergeBranch，合并入master：

$ git checkout master
$ git merge mergeBranch

合并后，master和mergeBranch都指向同一个版本，能够删除掉mergeBranch了：

$ git branch -d mergeBranch

1.2　分支建立与合并的实例

Task:

1. 开发某项目。
2. 为实现某个新的需求，建立一个分支iss53。
3. 在这个分支上开展工做。

　　　假设临时有个很严重的其余问题须要紧急修补，按照下面的方式处理：

1. 返回master分支。
2. 为此次紧急修补创建一个新分支hotfix，并在其中修复问题。
3. 经过测试后，回到服务器所在的master分支，将修补分支合并进来，而后再推送到服务器上。
4. 删除hotfix
5. 切换到以前实现新需求的分支iss53，继续工做。

　　　工做完成之后，将分支iss53合并入master

　　若是iss53与hotfix工做没有冲突，则合并成功，若是有冲突则须要再进行处理判断后，再合并。

Do:

一、假设当前，master更新为C2版本：

   

二、为实现某功能建立iss53分支，建立index.html，并上传

这个时候，状态是这样的：

三、紧急任务来了，要先返回master分支

四、如今接到进行紧急修改的要求，而后建立hotfix

五、进行了相应的开发，包括修改index.html(注意，在iss53中也进行了修改)

而后git push origin hotfix。

Git 会把工做目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当时提交时彻底同样。

因而当前的状态是：

六、当分支hotfix的内容测试经过确认后，就能够合并到master中，并删除hotfix

若是顺着一个分支走下去能够到达另外一个分支的话，那么 Git 在合并二者时，只会简单地把指针右移，由于这种单线的历史分支不存在任何须要解决的分歧，因此这种合并过程能够称为快进（Fast forward）。

如今最新的修改已经合并到master分支了。能够发布啦。

接下来删除hotfix

七、如今咱们回到iss35继续工做

咱们继续推动iss35:

八、如今接下来要合并master和iss53

合并后，删除iss53分支，便可。

请注意，此次合并操做的底层实现，并不一样于以前 hotfix 的并入方式。由于此次你的开发历史是从更早的地方开始分叉的。因为当前 master 分支所指向的提交对象（C4）并非 iss53 分支的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）以及它们的共同祖先（C2）进行一次简单的三方合并计算。

此次，Git 没有简单地把分支指针右移，而是对三方合并后的结果从新作一个新的快照，并自动建立一个指向它的提交对象（C6）（见图 3-17）。这个提交对象比较特殊，它有两个祖先（C4 和 C5）。

值得一提的是 Git 能够本身裁决哪一个共同祖先才是最佳合并基础；这和 CVS 或 Subversion（1.5 之后的版本）不一样，它们须要开发者手工指定合并基础。因此此特性让 Git 的合并操做比其余系统都要简单很多。

九、可是若是在不一样的分支中都修改了同一个文件的同一部分，Git 就没法干净地把二者合到一块儿（译注：逻辑上说，这种问题只能由人来裁决。）。若是你在解决问题 #53 的过程当中修改了 hotfix 中修改的部分，则会出现：

咱们先看一下状态：

接下来咱们能够打开 index.html

git 已经自动对其作了区分，HEAD表示master分支的内容，=====下面的是iss53分支作的修改

你能够对其再作调整和修改。

再用git add index.html，git commit表示他们已经解决冲突。

而后再融合和删除iss53分支。完成工做。

也可使用mergetool：

2. Git分支在实际项目中的灵活运用

这是Git版本控制的分支管理整体图：

 

 其中最重要的是主分支：

• master：用来版本发布，主要反映当前线上运行的代码。
• develop：做为开发分支，用来存放最新开发的代码，有时候会叫它“集成分支”。

develop分支用来存放开发完成的代码，当develop分支上的代码测试没有问题后，merge到master分支上，并发布。

辅助分支：

• feature branches

feature分支也能够叫作主题分支。例如在新版中要开发的新功能，能够用feature来存放。名字能够另外取，例如要增长insert和search功能，能够增长insertFeature和searcheFeature的分支，开发好后，再分别merge到develop分支中。

从 develop 分支建一个 feature 分支，并切换到 feature 分支 

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

　　

 

合并feature 分支到 develop

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

　　其中--no-ff 的参数，ff表示fastforward，--no--ff，就表示会对历史的分支作一个新的提交对象。加参数和不加参数的区别以下：（可使用 sourceTree 或者命令git log --graph查看）

 

• release branches

这个分支能够是来自develop；必须合并到develop和master。release分支能够理解为更多的是做为版本控制、缺陷镜像修复和最后发布前的复查工做。

建立一个realase分支

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

　　这里的bump-version.sh ，只是一个虚拟的脚本，是要求读者本身去编写这样的脚本，实现相应的地方都统一更改版本号。

完成release分支：

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

　　融合到develop分支

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

　　删除release分支

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

　　

• hotfix branches

这个是一个须要紧急修复bug的分支。当线上产品有bug，咱们能够开一个hotfix分支，修复完bug后，再merge，删除。

它来自master，融合向develop和master。

关系以下：

具体代码以下：

建立hotfix分支：

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

　　

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

　　完成了hotfix分支：

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

　　合并到develop分支

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

　　最后删除hotfix分支

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).

　　

参考：

【1】 http://nvie.com/posts/a-successful-git-branching-model/

【2】http://blog.jobbole.com/109466/

【3】https://git-scm.com/book/zh/v1/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E6%96%B0%E5%BB%BA%E4%B8%8E%E5%90%88%E5%B9%B6