Git 版本控制 branch model 分支模型基本介绍

我相信大家对于 Git 版本控制不陌生了，Git 最大强项就是可以任意建立
branch，让您开发程序不需要担心原本的程序代码会被动到，造成不知道该怎么
恢复原来的状态。为了不影响产品发展，branch 对于大型工作团队就显得更重要
了，今天在网络上看到一篇 A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/ 文章，里面把
branch 使用方式写得非常清楚，底下我会透过指令来说明如何使用简单 branch
指令，当然请大家先去 github 或者 https://bitbucket.org 注册申请帐号，如果不想申请帐号，也可以自己

在 local 端去执行。我用的是bitbucket.org这个服务器，前面的文章我已经介绍

了这个服务器，支持免费的私有仓库，所以我选择了它。

底下所引用的图片都是经由 A successful Git branching model 文章所提供。

看到这张图其实就说明了 branch 最重要的精神:『无限建立分支』，

大家也不用害怕看不懂这张图，底下会看图讲故事说明 branch 分支状况

主要分支

    master 主程序(除非重大 bug，则会分出 hotfix 分支)
    develop 开发分支(用来再另外分支出 Release, feature)

次要分支

    Hotfixes(由 master 直接分支，马上修正 bug)
    Feature(由 develop 直接分支，开发新功能)
    Release(由 develop 直接分支，开发下一版 Release)


一、主要分支 ( The main branches )


当开发开始执行时，我们这时候必须将程序代码分成两部份，一个是 master 另
一个就是 develop，master 主要用来 Release 产品专用，没事就不要去动它，
假如要继续开发新功能，或者是修正 Bug issue 就利用 develop 这分支来开发，
等待开发完成，要 Release 下一版产品时就将 develop merge 到
origin/master 分支，这样才对，避免有人把 origin/master 改烂，底下这张图
就说明了一切:





二、次要分支 ( Supporting branches )

次要分支这里包含了  Feature, Release，Hotfixes。

Feature 跟 Release 都是从 develop 分支出来，最后都merge 回 develop branch，然后主分支 master 

再去 merge develop，这样就完成了。

其中 Hotfixes 用来修正产品最重大 bug，所以由 origin/master 直接分支出来，修正之后在 merge 回master 跟 develop。

上面的例子，不一定套用在各开发过各中，因为 branch 免费，要多少有多少，

不一定完全都要 follow 此方法。


2.1、新功能分支 ( Feature branches )


branch off from: develop
Must merge back into: develop





看到上面图说明，我想大家都很清楚，develop 分支出 Feature branch，用来开
发产品新功能，等到开发完整之后，在直接 merge 回 develop，下面直接用实际
例子来操作:

直接由 develop 开出分支 myfeature，并且直接切换过去

 git checkout -b myfeature develop
 # 直接用 git branch 观看目前位置
  develop
  master
  * myfeature

经过编辑修改并且 commit
git add test.php

 git commit -a -m "Add: test.php"

合并分支:
先切换到 develop
$ git checkout develop

 Switched to branch 'develop'

利用 --no-ff 合并分支(稍后说明为什么使用 --no-ff)

$ git merge --no-ff myfeature

 Merge made by recursive.
  test.php |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
  create mode 100644 test.php

删除 myfeature 分支

 $ git branch -d myfeature
 Deleted branch myfeature (was dedf7ed).

将资料上传

 $ git push origin develop

在说明 git merge --no-ff 之前，大家先看底下的图。

有没有很清楚发现差别，右边是正常的 merge，会将原本的 commit log 合并成
一条，然而如果加上 --no-ff option 的话，commit log 会纪录您是开分支出去
的，清楚纪录您的分支操作步骤，建议大家多使用此方法，毕竟预设的 merge 看
到的效果不是我想要的。


2.2、Release branches


May branch off from: develop
Must merge back into: develop and master


Release branch 跟 feature branch 不同点就是: 前者需要 merge 回 master，
后者不需要，所以操作步骤会多一点，但是观念不变啦。底下实际看个例子，操
作一次，大家就可以熟悉了。


从 develop 开新分支 release-1.3  

 git checkout -b release-1.3 develop

经过一堆 commit message

 git commit -a -m "Update: release 1.3"

切回去主分支 master

 git checkout master

master 合并 release-1.3 分支

 git merge --no-ff release-1.3

在 master 上面加上新 tag

 git tag -a v1.3 -m "Release v1.3 Tag"

切换到 develop 分支

 git checkout develop

一样是 merge release-1.3

 git merge --no-ff release-1.3

上传资料  

 git push

将新 Tag v1.3 更新到 origin/master

 git push origin v1.3

删除 release-1.3 分支

 $ git branch -d release-1.3
   Deleted branch release-1.3 (was 2c92042).

2.3、重大 issue 分支 ( Hotfix branches )


May branch off from: master
Must merge back into: develop and master
Branch naming 命名方式: hotfix-*




当我们产品线发现 critical bug 时，这就要从 master 拉出 hotfix-* 分支，
尽快将 bug 解决，并且同时 merge 到 develop 跟 master，底下实际例子操作:


从 master 开新分支 release-1.3

 git checkout -b hotfix-1.3.1 master

修改代码，并且 commit

 git commit -a -m "Hotfix: release 1.3.1"

切换到 master

 git checkout master

merge hotfix-1.3.1 分支

 git merge --no-ff hotfix-1.3.1

加上修正过后的 Tag

 git tag -a v1.3.1 -m "Hotfix v1.3.1 Tag"

切换到 develop 分支   

 git checkout develop

一样是 merge hotfix-1.3.1 分支

 git merge --no-ff hotfix-1.3.1

合并过后就删除 hotfix-1.3.1 分支

 git branch -d hotfix-1.3.1

上传资料

 git push

将 Tag v1.3.1 上传

 git push origin v1.3.1

看完上面例子，是否清楚了解 branch 的基本用法，其实不会很难，看图说故事而已。

备注： 执行git push 的时候会提交  所有分支（但同时在服务器也存在相同的分支）到服务器上，

(即，本地有某个分支，但服务器不存在该分支， git push是不会提交这个分支的）

如果想避免一起提交，（可能在其它分支上的工作还没有完成），就需要设置一下git push的

默认行为。

 git config --global push.default tracking

这样一来，执行git push时，只会提交当前工作的分支到服务上。

FAQ： 

1. What does git push -u mean?

I have two different versions of git. In the 1.6.2 version, git push
does not have the -u option. It only appears in the 1.7.x version.


From the docs, the -u  --set-upstream  is related to the variable


branch.<name>.merge


in git config. This variable is described below:


Defines, together with branch.<name>.remote, the upstream branch for
the given branch. It tells git fetch/git pull which branch to merge.


What is an upstream branch ?




Answer: 


"Upstream" would refer to the main repo that other people will be
pulling from, e.g. your GitHub repo. The -u option automatically sets
that upstream for you, linking your repo to a central one. That way,
in the future, Git "knows" where you want to push to and where you
want to pull from, so you can use git pull or git push without
arguments. 

2. 怎么把本地分支提交到服务器上，（服务器上不存在该分支）

答： 

假如你有分支 test, 做如下操作：

 git push origin test

这句的意思是，把本地分支test提交到远程的origin仓库中）

（ git中， origin  代表是远程服务器上的仓库）

我们可以查看 .git/config  中的 origin的定义， 就知道origin指向什么地方了（注意：只有用git clone的仓库才存在该字段，你也可以手动添加）

3. Can I make fast forwarding be off by default in git?

Answer: 

we can use the following:

 git config --global --add merge.ff false

(merge.ff was introduced in  Git 1.7.6 )


From the documentation (search for merge.ff):


merge.ff


By default, git does not create an extra merge commit when
merging a commit that is a descendant of the current commit.
Instead, the tip of the current branch is  f ast- f orwarded.  When
set to false, this variable tells git to create an extra merge
commit in such a case (equivalent to giving the --no-ff option
from the command line).  When set to only, only such fast-forward
merges are allowed (equivalent to giving the --ff-only option
from the command line).

from: http://blog.wu-boy.com/2011/03/git-%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6-branch-model-%E5%88%86%E6%94%AF%E6%A8%A1%E7%B5%84%E5%9F%BA%E6%9C%AC%E4%BB%8B%E7%B4%B9/