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

  • 时间:
  • 浏览:8
  • 来源:uu快3手机版ios_uu快3app邀请码_在线官网

在这篇文章中,我提出三个多 开发模型。我原因分析将有有一种开发模型引入到我所有的项目里(无论在工作还是私人)原因分析一年有余,好多好多 我它被证明是非常成功的。我打算写那些原因分析但是了,但我老是没法时间来做,现在终于有时间了。我不让讲任何项目的具体细节,仅是关于分支策略和释放管理相关内容。

hotfix branch(修补bug分支)是从Master分支底下分出来的。类式,1.2版本是当前生产环境的版本好多好多 我有bug。好多好多 我开发分支(develop)变化还不稳定。亲戚亲戚朋友可不上能 分出来三个多 修补bug分支(hotfix branch)来正确处理有有一种状态。

但是现在开始一项功能的开发工作时,基于develop创建分支。

234567

Deleted branch release-1.2 (was ff452fe).

完成三个多 bugfix以前,可不上能 把bugfix合并到master和develop分支去,原先就可不上能 保证修复的有有一种bug也包含到下三个多 发行版中。有有一种点和完成release分支很类式。

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



在核心主次,研发模型很大程度上靠或多或少现有模型支撑的。中心库有三个多 可老是延续的分支:

对于有有一种分支模型,亲戚亲戚朋友设置了三个多 版本库,它运转良好,这是三个多 ”事实上” 版本库。不过请注意,有有一种版本库好多好多 我被认为是中心版本库(原因分析Git是三个多 分布式版本管理系统,从技术上来讲,并没法 三个多 中心版本库)。亲戚亲戚朋友将把有有一种版本库称为原始库,有有一种名字对所有的Git用户来说都很容易理解。



每个开发者都对origin库拉代码和提交代码。好多好多 我除了集中式的存取代码关系,每个开发者也可不上能 从子团队的或多或少队友那里获得代码版本变更。类式,对于三个多 或多个开发者同去完成的大版本变更,为了正确处理过早地向origin库提交工作内容,有有一种机制就变得非常有用。在上述途中,有如下子团队:Alice和Bob,Alice和David,Clair和David。

从技术上将,这原因分析,Alice创建了三个多 Git的远程节点,而对于Bob,该节点指向了Bob的版本库,反之亦然。

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

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

2345678

2345

23

234567

有有一种步骤原因分析会原因分析合并冲突(原因分析原因分析改变版本号更是没法 )。原因分析是原先,修复它好多好多 我提交。

现在亲戚亲戚朋友真正的完成了,有有一种release分支将被删除,原因分析亲戚亲戚朋友不再可不上能 它了。

2

–no-ff标志原因分析合并操作创建三个多 新commit对象,即使该合并操作可不上能 fast-forward。这正确处理了丢失有有一种功能分支位于的历史信息,将该功能的所有提交组合在同去。 比较:



后有有一种状态,不原因分析从Git历史中看到那些提交同去实现了三个多 功能——你可不上能 手工阅读删剪的日志信息。原因分析对整个功能进行回退 (比如一组提交),后有有一种最好的最好的办法会是有有一种真正头痛的大问題,而使用–no-ff参数的状态则很容易.

是的,它会创建三个多 新的(空)提交对象,好多好多 我收益远大于开销。

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

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分支是从develop分支创建的。类式,当前产品的发行版本号为1.1.5,同事亲戚亲戚朋友有三个多 大的版本即将发行。develop 分支愿原因分析下次发行做好了准备,亲戚亲戚朋友得决定下三个多 版本是1.2(而删剪都会1.1.6原因分析2.0)。好多好多 有亲戚亲戚朋友将Release分支分离出来,给三个多 要能反映新版本号的分支名。

规则的三个多 例外是:原因分析三个多 release分支原因分析位于,没法 应该把hotfix合并到有有一种release分支,而删剪都会合并到develop分支。当release分支完成后, 将bugfix分支合并回release分支也会使得bugfix被合并到develop分支。(原因分析在develop分支的工作急需有有一种bugfix,等不到release分支的完成,那你也可不上能 把bugfix合并到develop分支)

最后,删除临下午英语 支:

亲戚亲戚朋友的开发模型使用了各种辅助性分支,那些分支与关键分支(master和develop)同去,用来支持团队成员们并行开发,使得易于追踪功能,协助生产发布环境准备,以及快速修复实时在线大问題。与关键分支不同,那些分支老是有三个多 有限的生命期,原因分析亲戚亲戚朋友最终会被移除。

亲戚亲戚朋友用到的分支类型包括:



原因分析是develop分支的分支版本,最终可不上能 合并到develop分支中。

分支命名规则:除了master、develop、release-*、hotfix-*之外,或多或少命名均可。

功能分支(有时被称为topic分支)通常为即将发布原因分析未来发布版开发新的功能。当新功能但是现在开始研发,包含该功能的发布版本在有有一种还是无法选则发布时间的。功能版本的实质是而且我有有一种功能位于开发状态它就会位于,好多好多 我最终会或合并到develop分支(选则将新功能加带到不久的发布版中)或取消(譬如一次令人失望的测试)。

功能分支通常位于于开发者的软件库,而删剪都会在源代码库中。

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

23456

当develop分支的源码到达了三个多 稳定状态待发布,所有的代码变更可不上能 以有有一种最好的最好的办法合并到master分支,好多好多 我标记三个多 版本号。怎么上能操作将在稍后删剪介绍。

好多好多 有,每次变更都合并到了master,这好多好多 我新产品的定义。在有有一种点,亲戚亲戚朋友倾向于严格执行有有一种点,从而,理论上,每当对master有三个多 提交操作,亲戚亲戚朋友就可不上能 使用Git钩子脚原先自动构建好多好多 我发布软件到生产服务器。

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

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

Switched to a new branch "myfeature"

当三个多 release分支准备好成为三个多 真正的发行版的以前,有或多或少工作可不上能 完成。首先,release分支要合并到master上(原因分析每一次提交到master上的删剪都会三个多 新定义的发行版,记住)。好多好多 我,提交到master上可不上能 打三个多 标签,以便以前更加方便的引用有有一种历史版本。最后,在release分支上的修改可不上能 合并到develop分支上,以便未来发行版也包含那些bugs的修复。

在Git中的前两步是:

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

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

英文原文:A successful Git branching model。

2

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

尽管有有一种分支模型没法 任何震撼的新东西, 文章开头的图表在亲戚亲戚朋友的项目中表现出惊人的实用性。它形成了三个多 优雅的思维模型,易于领悟并使团队成员发展出对分支和发布过程的同去理解。

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

更新:原因分析一群人可不上能 : 这是主图表的gitflow-model.src.pdf。

2015.08.19更新:主图表也可不上能 到这下载。

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

好多好多 我,修复bug,一次提交原因分析多次分开提交。

为了是修改保持在release分支上,亲戚亲戚朋友可不上能 合并那些到develop分支上去,在Git上:

23456

修订:你原因分析也想使用-s或-u 参数来标记你的标签。

下一步,把bugfix加带到develop分支中:

每个Git用户删剪都会熟悉原始的master分支。与master分支并行的原先分支,亲戚亲戚朋友称之为develop分支。

亲戚亲戚朋友把原始库/master库认作为主分支,HEAD的源代码位于于此版本中,好多好多 我随时删剪都会三个多 入党的程序生产状态。

每有有一种分支有三个多 特定目的,好多好多 我受限于严格到规则,比如:可不上能 用那些分支作为源分支,那些分支能作为合并目标。亲戚亲戚朋友马上将进行演练。

从技术深层来看,那些分支绝删剪都会特殊分支。分支的类型基于亲戚亲戚朋友使用的最好的最好的办法来进行分类。它们理所当然是普通的Git分支。



可不上能 基于master分支,可不上能 合并回develop和master分支。

分支名约定:hotfix-*

热修复分支与发布分支很类式,亲戚亲戚朋友都为新的生成环境发布做准备,尽管这是未经计划的。亲戚亲戚朋友来自生产环境的位于异常状态压力。当生成环境验证不够可不上能 马上修复是,热修复分支可不上能 基于master分支上对应与线上版本的tag创建。

其本质是团队成员(在develop分支上)的工作可不上能 继续,而原先人准备生产环境的快速修复。

发行版现在原因分析完成,为以前引用打上标签。

修订:你原因分析也想使用-s或-u 参数来标记你的标签。

创建新分支以前,切换到该分支,加带版本号。这里,bump-version.sh 是三个多 虚构的shell脚本,它可不上能 克隆好友或多或少文件来反映新的版本(这当然可不上能 手动改变–目的好多好多 我修改或多或少文件)。好多好多 我版本号被提交。

有有一种新分支原因分析会位于一段时间,直到该发行版到达它的预定目标。在此期间,bug的修复原因分析被提交到该分支上(而删剪都会提交到develop分支上)。在这里严格禁止增加大的新features。亲戚亲戚朋友可不上能 合并到develop分支上,好多好多 我等待时间下一次大的发行版。

2

亲戚亲戚朋友把origin/develop库认为是主分支,该分支HEAD源码始终体现下个发布版的最新软件变更。一群人称有有一种为“集成分支”,而这是每晚自动构建得来的。

2345

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

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

好多好多 我对于Git来说,那些行为非常简单和搞笑,它们被认为是日常工作中的核心主次。类式,在好多好多 有CVS/Subversion书里,分支与合并老是在底下的章节中被讨论(对于高级用户使用),然而在每个Git书中,在第3章就原因分析删剪包含了(作为基础)。

简单和重复的行态带来的结果是:分支与合无须再是那些可不上能 害怕的东西。分支/合并被认为对于版本管理工具比或多或少功能更重要。

关于工具,不再多说,让亲戚亲戚朋友直接看开发模型吧。有有一种模型并删剪都会如下模型:在管理软件开发进度方面,面对每个开发过程,每个队员可不上能 按一定次序开发。

Deleted branch hotfix-1.2.1 (was abbe5d6).

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