Git基础06:介绍一个成功的 Git 分支模型

  • 时间:
  • 浏览:0
  • 来源:UU直播快三官方_大发UU直播快3

234567

让让我们 把origin/develop库认为是主分支,该分支HEAD源码始终体现下个发布版的最新软件变更。一帮人称你你这些为“集成分支”,而这是每晚自动构建得来的。

hotfix branch(修补bug分支)是从Master分支上端分出来的。类式,1.2版本是当前生产环境的版本什么都 我有bug。什么都 我开发分支(develop)变化还不稳定。让让我们 不前会 分出来另另一一兩个修补bug分支(hotfix branch)来避免你你这些具体情况。

Switched to a new branch "hotfix-1.2.1"$ ./bump-version.sh 1.2.1Files 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.11 files changed, 1 insertions(+), 1 deletions(-)

在这篇文章中,我提出另另一一兩个开发模型。我可能将你你这些开发模型引入到我所有的项目里(无论在工作还是私人)可能一年有余,什么都 我它被证明是非常成功的。我打算写有有哪些可能并且 了,但我经常找必须时间来做,现在终于有时间了。我无需讲任何项目的具体细节,仅是关于分支策略和释放管理相关内容。

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

23456

创建新分支前一天,切换到该分支,打上去版本号。这里,bump-version.sh 是另另一一兩个虚构的shell脚本,它前会 克隆qq你你这些文件来反映新的版本(这当并且 能 手动改变–目的什么都 我修改你你这些文件)。什么都 我版本号被提交。

你你这些新分支可能会处于一段时间,直到该发行版到达它的预定目标。在此期间,bug的修复可能被提交到该分支上(而总要 提交到develop分支上)。在这里严格禁止增加大的新features。让让我们 不前会 合并到develop分支上,什么都 我等待时间下一次大的发行版。

2

Deleted branch hotfix-1.2.1 (was abbe5d6).

23456

Release分支是从develop分支创建的。类式,当前产品的发行版本号为1.1.5,同事让让我们 另另一一兩个大的版本即将发行。develop 分支可能为下次发行做好了准备,让让我们 得决定下另另一一兩个版本是1.2(而总要 1.1.6可能2.0)。什么都 让让我们 将Release分支分离出来,给另另一一兩个无需前会 反映新版本号的分支名。

开始英文英文英语 一项功能的开发工作时,基于develop创建分支。

让让我们 的开发模型使用了各种辅助性分支,有有哪些分支与关键分支(master和develop)共同,用来支持团队成员们并行开发,使得易于追踪功能,协助生产发布环境准备,以及快速修复实时在线问提。与关键分支不同,有有哪些分支经常另另一一兩个有限的生命期,可能让让我们 最终会被移除。

让让我们 用到的分支类型包括:

2345



前会 基于master分支,不前会 合并回develop和master分支。

分支名约定:hotfix-*

热修复分支与发布分支很类式,让让我们 都为新的生成环境发布做准备,尽管这是未经计划的。让让我们 来自生产环境的处于异常具体情况压力。当生成环境验证不够不前会 马上修复是,热修复分支前会 基于master分支上对应与线上版本的tag创建。

其本质是团队成员(在develop分支上)的工作前会 继续,而另一另一方准备生产环境的快速修复。



可能是develop分支的分支版本,最终不前会 合并到develop分支中。

分支命名规则:除了master、develop、release-*、hotfix-*之外,你你这些命名均可。

功能分支(有时被称为topic分支)通常为即将发布可能未来发布版开发新的功能。当新功能开始英文英文英语 研发,中含 该功能的发布版本在你你这些还是无法选泽发布时间的。功能版本的实质是假如有一天你你这些功能处于开发具体情况它就会处于,什么都 我最终会或合并到develop分支(选泽将新功能打上去到不久的发布版中)或撤除(譬如一次令人失望的测试)。

功能分支通常处于于开发者的软件库,而总要 在源代码库中。

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

2345678

[hotfix-1.2.1 abbe5d6] Fixed severe production problem5 files changed, 32 insertions(+), 17 deletions(-)

对于Git与你你这些集中式代码管理工具相比的优缺点的全面讨论,请参见这里。另另一一兩个的争论经常喋喋不休。作为另另一一兩个开发者,与现今的你你这些开发工具相比较,我更喜欢Git。Git真得改变了开发者对于合并和分支的思考。我另另一一兩个使用经典的CVS/Subversion,然而每次的合并/分支和你你这些行为总我想要担惊受怕(“小心合并里的冲突,你造要命!”)。

什么都 我对于Git来说,有有哪些行为非常简单和搞笑,它们被认为是日常工作中的核心每项。类式,在什么都 CVS/Subversion书里,分支与合并经常在上端的章节中被讨论(对于高级用户使用),然而在每个Git书中,在第3章就可能完整版中含 了(作为基础)。

简单和重复的型态带来的结果是:分支与合无须再是有哪些前会 害怕的东西。分支/合并被认为对于版本管理工具比你你这些功能更重要。

关于工具,不再多说,让让我们 歌词 直接看开发模型吧。你你这些模型并总要 如下模型:在管理软件开发进度方面,面对每个开发过程,每个队员不前会 按一定次序开发。

完成的功能前会 合并进develop分支,以明确加入到未来的发布:

每个Git用户总要 熟悉原始的master分支。与master分支并行的另另一一兩个分支,让让我们 称之为develop分支。

让让我们 把原始库/master库认作为主分支,HEAD的源代码处于于此版本中,什么都 我随时总要 另另一一兩个预备生产具体情况。

对于你你这些分支模型,让让我们 设置了另另一一兩个版本库,它运转良好,这是另另一一兩个”事实上” 版本库。不过请注意,你你这些版本库什么都 我被认为是中心版本库(可能Git是另另一一兩个分布式版本管理系统,从技术上来讲,并没另另一一兩个中心版本库)。让让我们 将把你你这些版本库称为原始库,你你这些名字对所有的Git用户来说都很容易理解。



每个开发者都对origin库拉代码和提交代码。什么都 我除了集中式的存取代码关系,每个开发者也前会 从子团队的你你这些队友那里获得代码版本变更。类式,对于另另一一兩个或多个开发者共同完成的大版本变更,为了避免过早地向origin库提交工作内容,你你这些机制就变得非常有用。在上述途中,有如下子团队:Alice和Bob,Alice和David,Clair和David。

从技术上将,这因为,Alice创建了另另一一兩个Git的远程节点,而对于Bob,该节点指向了Bob的版本库,反之亦然。

规则的另另一一兩个例外是:可能另另一一兩个release分支可能处于,没法 应该把hotfix合并到你你这些release分支,而总要 合并到develop分支。当release分支完成后, 将bugfix分支合并回release分支也会使得bugfix被合并到develop分支。(可能在develop分支的工作急需你你这些bugfix,等必须release分支的完成,那你也前会 把bugfix合并到develop分支)

最后,删除临时分支:

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

2345

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

你你这些步骤可能会因为合并冲突(可能可能改变版本号更是没法 )。可能是另另一一兩个,修复它什么都 我提交。

现在让让我们 真正的完成了,你你这些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分支创建时根据项目在版本号上的规则制定的。

分支关闭的时侯无须忘了更新版本号(bump the version)

什么都 我,修复bug,一次提交可能多次分开提交。

2

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

当另另一一兩个release分支准备好成为另另一一兩个真正的发行版的前一天,有你你这些工作不前会 完成。首先,release分支要合并到master上(可能每一次提交到master上的总要 另另一一兩个新定义的发行版,记住)。什么都 我,提交到master上不前会 打另另一一兩个标签,以便前一天更加方便的引用你你这些历史版本。最后,在release分支上的修改不前会 合并到develop分支上,以便未来发行版也中含 晒 有哪些bugs的修复。

在Git中的前两步是:

为了是修改保持在release分支上,让让我们 不前会 合并有有哪些到develop分支上去,在Git上:

完成另另一一兩个bugfix前一天,不前会 把bugfix合并到master和develop分支去,另另一一兩个就前会 保证修复的你你这些bug也中含 到下另另一一兩个发行版中。这你你这些和完成release分支很类式。

首先,更新master并对release打上tag:

Switched to a new branch "myfeature"

修订:你可能也想使用-s或-u 参数来标记你的标签。

下一步,把bugfix打上去到develop分支中:

Deleted branch release-1.2 (was ff452fe).



在核心每项,研发模型很大程度上靠你你这些现有模型支撑的。中心库有另另一一兩个可经常延续的分支:

234567

每有一种分支另另一一兩个特定目的,什么都 我受限于严格到规则,比如:前会 用有哪些分支作为源分支,有哪些分支能作为合并目标。让让我们 马上将进行演练。

从技术层厚来看,有有哪些分支绝总要 特殊分支。分支的类型基于让让我们 使用的最好的方法来进行分类。它们理所当然是普通的Git分支。

2

发行版现在可能完成,为前一天引用打上标签。

修订:你可能也想使用-s或-u 参数来标记你的标签。

本文转自开源中国社区,修复了几处文字错误。文章译者:Lax,xue777hua,FGQ,showme,Tocy,lidashuang,JoeyBlue。

英文原文:A successful Git branching model。

尽管你你这些分支模型没法 任何震撼的新东西, 文章开头的图表在让让我们 的项目中表现出惊人的实用性。它形成了另另一一兩个优雅的思维模型,易于领悟并使团队成员发展出对分支和发布过程的共同理解。

这里提供一份高质量PDF格式图表。去吧,把它挂载墙上以便能随时快速参考。

更新:可能一帮人不前会 : 这是主图表的gitflow-model.src.pdf。

2015.08.19更新:主图表也前会 到这下载。

Switched to a new branch "release-1.2"$ ./bump-version.sh 1.2Files 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.21 files changed, 1 insertions(+), 1 deletions(-)

–no-ff标志因为合并操作创建另另一一兩个新commit对象,即使该合并操作前会 fast-forward。这避免了丢失你你这些功能分支处于的历史信息,将该功能的所有提交组合在共同。 比较:



后有一种具体情况,可能从Git历史中看了有哪些提交共同实现了另另一一兩个功能——你不前会 手工阅读完整版的日志信息。可能对整个功能进行回退 (比如一组提交),后有一种最好的方法会是有一种真正头痛的问提,而使用–no-ff参数的具体情况则很容易.

是的,它会创建另另一一兩个新的(空)提交对象,什么都 我收益远大于开销。

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

23

当develop分支的源码到达了另另一一兩个稳定具体情况待发布,所有的代码变更不前会 以有一种最好的方法合并到master分支,什么都 我标记另另一一兩个版本号。要怎样操作将在稍后完整版介绍。

什么都 ,每次变更都合并到了master,这什么都 我新产品的定义。在这你你这些,让让我们 倾向于严格执行这你你这些,从而,理论上,每当对master另另一一兩个提交操作,让让我们 就前会 使用Git钩子脚另另一一兩个自动构建什么都 我发布软件到生产服务器。