介绍一个成功的 Git 分支模型(2)_开源配置管理工具

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

发表于：2013-04-02来源：伯乐在线作者：不详点击数：标签：Git

1 2 3 4 5 6 7 8 $ 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 0

						$ 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标志导致合并操作创建一个新commit对象，即使该合并操作可以fast-forward。这避免了丢失这个功能分支存在的历史信息，将该功能的所有提交组合在一起。比较:

　　后一种情况，不可能从Git历史中看到哪些提交一起实现了一个功能——你必须手工阅读全部的日志信息。如果对整个功能进行回退 (比如一组提交)，后一种方式会是一种真正头痛的问题，而使用–no-ffflag的情况则很容易.

　　是的，它会创建一个新的(空)提交对象，但是收益远大于开销。

　　不幸的是，我还没找到一种方法，让–no-ff时作为合并操作的默认选项，但它应该是可行的。

　　Release 分支

　　Release分支可能从develop分支分离而来，但是一定要合并到develop和master分支上，它的习惯命名方式为：release-*。

　　Release分支是为新产品的发布做准备的。它允许我们在最后时刻做一些细小的修改。他们允许小bugs的修改和准备发布元数据(版本号，开发时间等等)。当在Release分支完成这些所有工作以后，对于下一次打的发布，develop分支接收features会更加明确。

　　从develop分支创建新的Release分支的关键时刻是develop分支达到了发布的理想状态。至少所有这次要发布的features必须在这个点及时合并到develop分支。对于所有未来准备发布的features必须等到Release分支创建以后再合并。

　　在Release分支创建的时候要为即将发行版本分配一个版本号，一点都不早。直到那时，develop分支反映的变化都是为了下一个发行版，但是在Release分支创建之前，下一个发行版到底叫0.3还是1.0是不明确的。这个决定是在Release分支创建时根据项目在版本号上的规则制定的。

　　创建一个release分支

　　Release分支是从develop分支创建的。例如，当前产品的发行版本号为1.1.5，同事我们有一个大的版本即将发行。develop 分支已经为下次发行做好了准备，我们得决定下一个版本是1.2(而不是1.1.6或者2.0)。所以我们将Release分支分离出来，给一个能够反映新版本号的分支名。

						$ 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(-)

原文转自：http://blog.jobbole.com/34706/

软件测试 > 开源软件测试 > 开源配置管理工具 >