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

  • 时间:
  • 浏览:0
  • 来源:uu直播快3平台_UU快3直播官方

当三个白 release分支准备好成为三个白 真正的发行版的前一天,有一点工作前要完成。首先,release分支要合并到master上(肯能每一次提交到master上的与非 三个白 新定义的发行版,记住)。怎么能让,提交到master上前要打三个白 标签,以便前一天更加方便的引用这人 历史版本。最后,在release分支上的修改前要合并到develop分支上,以便未来发行版也蕴藏哪些bugs的修复。

在Git中的前两步是:

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

Switched to a new branch "myfeature"

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



每个开发者都对origin库拉代码和提交代码。怎么能让除了集中式的存取代码关系,每个开发者也可不前要从子团队的一点队友那里获得代码版本变更。类事,对于三个白 或多个开发者一块儿完成的大版本变更,为了处里过早地向origin库提交工作内容,这人 机制就变得非常有用。在上述途中,有如下子团队:Alice和Bob,Alice和David,Clair和David。

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

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

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

–no-ff标志意味合并操作创建三个白 新commit对象,即使该合并操作可不前要fast-forward。这处里了丢失这人 功能分支发生的历史信息,将该功能的所有提交组合在一块儿。 比较:



后一种情况汇报,不肯能从Git历史中都看哪些提交一块儿实现了三个白 功能——你前要手工阅读完整的日志信息。肯能对整个功能进行回退 (比如一组提交),后一种土办法会是一种真正头痛的问题,而使用–no-ff参数的情况汇报则很容易.

是的,它会创建三个白 新的(空)提交对象,怎么能让收益远大于开销。

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

234567

2345678

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

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

英文原文:A successful Git branching model。

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

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

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

更新:肯能这样人前要: 这是主图表的gitflow-model.src.pdf。

2015.08.19更新:主图表也可不前要到这下载。

23

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

完成三个白 bugfix前一天,前要把bugfix合并到master和develop分支去,这样 就可不前要保证修复的这人 bug也蕴藏到下三个白 发行版中。这人 点和完成release分支很类事。

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

这人 步骤肯能会意味合并冲突(肯能肯能改变版本号更是这样 )。肯能是这样 ,修复它怎么能让提交。

现在朋友真正的完成了,这人 release分支将被删除,肯能朋友不再前要它了。

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

2

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

怎么能让对于Git来说,哪些行为非常简单和搞笑,它们被认为是日常工作中的核心次责。类事,在所以CVS/Subversion书里,分支与合并三个白 劲在后面 的章节中被讨论(对于高级用户使用),然而在每个Git书中,在第3章就肯能完整蕴藏了(作为基础)。

简单和重复的特性带来的结果是:分支与合并不再是哪些可不前要害怕的东西。分支/合并被认为对于版本管理工具比一点功能更重要。

关于工具,不再多说,让朋友直接看开发模型吧。这人 模型虽然如下模型:在管理软件开发进度方面,面对每个开发过程,每个队员前要按一定次序开发。

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

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

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

Deleted branch release-1.2 (was ff452fe).



在核心次责,研发模型很大程度上靠一点现有模型支撑的。中心库有三个白 可三个白 劲延续的分支:

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

2345

每一种分支三个白 多特定目的,怎么能让受限于严格到规则,比如:可不前要用哪些分支作为源分支,哪些分支能作为合并目标。朋友马上将进行演练。

从技术厚度来看,哪些分支绝与非 特殊分支。分支的类型基于朋友使用的土办法来进行分类。它们理所当然是普通的Git分支。

Deleted branch hotfix-1.2.1 (was abbe5d6).

23456

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分支创建时根据项目在版本号上的规则制定的。



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

分支名约定:hotfix-*

热修复分支与发布分支很类事,朋友都为新的生成环境发布做准备,尽管这是未经计划的。朋友来自生产环境的发生异常情况汇报压力。当生成环境验证严重不足前要马上修复是,热修复分支可不前要基于master分支上对应与线上版本的tag创建。

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

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

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

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

规则的三个白 例外是:肯能三个白 release分支肯能发生,这样 应该把hotfix合并到这人 release分支,而与非 合并到develop分支。当release分支完成后, 将bugfix分支合并回release分支也会使得bugfix被合并到develop分支。(肯能在develop分支的工作急需这人 bugfix,等必须release分支的完成,那你也可不前要把bugfix合并到develop分支)

最后,删除临时段支:

2

23456

为了是修改保持在release分支上,朋友前要合并哪些到develop分支上去,在Git上:

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

这人 新分支肯能会发生一段时间,直到该发行版到达它的预定目标。在此期间,bug的修复肯能被提交到该分支上(而与非 提交到develop分支上)。在这里严格禁止增加大的新features。朋友前要合并到develop分支上,怎么能让等待图片下一次大的发行版。

Release分支是从develop分支创建的。类事,当前产品的发行版本号为1.1.5,同事朋友三个白 多大的版本即将发行。develop 分支肯能为下次发行做好了准备,朋友得决定下三个白 版本是1.2(而与非 1.1.6肯能2.0)。所以朋友将Release分支分离出来,给三个白 不需要可不能能 反映新版本号的分支名。

234567

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

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

怎么能让,修复bug,一次提交肯能多次分开提交。



肯能是develop分支的分支版本,最终前要合并到develop分支中。

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

功能分支(有时被称为topic分支)通常为即将发布肯能未来发布版开发新的功能。当新功能结束英文英文研发,蕴藏该功能的发布版本在这人 还是无法选则发布时间的。功能版本的实质是怎么能让我这人 功能发生开发情况汇报它就会发生,怎么能让最终会或合并到develop分支(选则将新功能加带到不久的发布版中)或撤消(譬如一次令人失望的测试)。

功能分支通常发生于开发者的软件库,而与非 在源代码库中。

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

2345

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

hotfix branch(修补bug分支)是从Master分支后面 分出来的。类事,1.2版本是当前生产环境的版本怎么能让有bug。怎么能让开发分支(develop)变化还不稳定。朋友前要分出来三个白 修补bug分支(hotfix branch)来处里这人 情况汇报。

2

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

每个Git用户与非 熟悉原始的master分支。与master分支并行的这样 分支,朋友称之为develop分支。

朋友把原始库/master库认作为主分支,HEAD的源代码发生于此版本中,怎么能让随时与非 三个白 预备党员生产情况汇报。

当develop分支的源码到达了三个白 稳定情况汇报待发布,所有的代码变更前要以一种土办法合并到master分支,怎么能让标记三个白 版本号。怎么能能操作将在稍后完整介绍。

所以,每次变更都合并到了master,这怎么能让我新产品的定义。在这人 点,朋友倾向于严格执行这人 点,从而,理论上,每当对master三个白 多提交操作,朋友就可不前要使用Git钩子脚这样 自动构建怎么能让发布软件到生产服务器。