一个成功的Git分支模型(2)

　　在第2张图中，已经无法一眼从Git历史中看到哪些commit对象构成了一个特性——你需要阅读日志以获得该信息。在这种情况下，回退(revert)整个特性(一组commit)就会比较麻烦，而如果使用了–no-diff就会简单很多。

　　是的，这么做会造成一些(空的)commit对象，但这么做是利大于弊的。

　　可惜的是，我没能找到方法让–no-diff成为默认的git merge行为参数，但其实应该这么做。

　　发布分支

　　可能的分支来源：develop

　　必须合并回：develop和master

　　分支命名约定：release-*

　　发布分支为准备新的产品版本发布做支持。它允许你在最后时刻检查所有的细节。此外，它还允许你修复小bug以及准备版本发布的元数据(例如版本号，构建日期等等)。在发布分支做这些事情之后，develop分支就会显得比较干净，也方便为下一大版本发布接受特性。

　　从develop分支创建发布分支的时间通常是develop分支(差不多)能反映新版本所期望状态的时候。至少说，这是时候版本发布所计划的特性都已经合并回了develop分支。而未来其它版本发布计划的特性则不应该合并，它们必须等到当前的版本分支创建好之后才能合并。

　　正是在发布分支创建的时候，对应的版本发布才获得一个版本号——不能更早。在该时刻之前，develop分支反映的是“下一版本”的相关变更，但不知道这“下一版本”到底会成为0.3还是1.0，直到发布分支被创建。版本号是在发布分支创建时，基于项目版本号规则确定的。

　　创建一个发布分支

　　发布分支从develop分支创建。例如，假设1.1.5是当前的产品版本，同时我们即将发布下个版本。develop分支的状态已经是准备好“下一版本”发布了，我们也决定下个版本是1.2(而不是1.1.6或者2.0)。因此我们创建发布分支，并且为其赋予一个能体现新版本号的名称：

　　$ git checkout -b releases-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是一个虚构的shell脚本，它修改一些本地工作区的文件以体现新的版本号。(当然这也可以手动完成——这里只是说要有一些文件变更)接着，提交新版本号。

　　新的发布分支可能存在一段时间，直到该版本明确对外交付。这段时间内，该分支上可能会有一些bug的修复(而不是在develop分支上)。在该分支上添加新特性是严格禁止的。新特性必须合并到develop分支，然后等待下一个版本发布。

　　结束一个发布分支

　　当发布分支达到一个可以正式发布的状态时，我们就需要执行一些操作。首先，将发布分支合并至master(记住，我们之前定义master分支上的每一个commit都对应一个新版本)。接着，master分支上的commit必须被打上标签(tag)，以方便将来寻找历史版本。最后，发布分支上的变更需要合并回develop，这样将来的版本也能包含相关的bug修复。

　　前两步在Git中的操作：

　　$ 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

　　现在版本发布完成了，而且为未来的查阅提供了标签。

　　提醒：你可能同时也会想要用 -s 或者 -u 来对标签进行签名。

　　为了能保留发布分支上的变更，我们还需要将分支合并回develop。在Git中：

　　$ git checkout develop

　　Switched to branch ‘develop’

　　$ git merge –no-ff release-1.2

　　Merge made by recursive.

　　(Summary of changes)

　　这一操作可能会导致合并冲突(可能性还很大，因为我们改变了版本号)。如果发现，则修复之并提交。

　　现在工作才算真正完成了，最后一步是删除发布分支，因为我们已不再需要它：

　　$ git branch -d release-1.2

　　Deleted branch release-1.2 (was ff452fe).

　　热补丁分支

　　必须合并回：develop和master

　　分支命名约定：hotfix-*

　　热补丁分支和发布分支十分类似，它的目的也是发布一个新的产品版本，尽管是不在计划中的版本发布。当产品版本发现未预期的问题的时候，就需要理解着手处理，这个时候就要用到热补丁分支。当产品版本的重大bug需要立即解决的时候，我们从对应版本的标签创建出一个热补丁分支。

　　使用热补丁分支的主要作用是(develop分支上的)团队成员可以继续工作，而另外的人可以在热补丁分支上进行快速的产品bug修复。

　　创建一个热补丁分支

　　热补丁分支从master分支创建。例如，假设1.2是当前正在被使用的产品版本，由于一个严重的bug，产品引起了很多问题。同时，develop分支还处于不稳定状态，无法发布新的版本。这时我们可以创建一个热补丁分支，并在该分支上修复问题：

　　$ 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.

原文转自：http://www.juvenxu.com/2010/11/28/a-successful-git-branching-model/