Git 中成功的分支模型

知道如何使用 Git 很重要, 这包括维护可管理的协作软件开发环境.

学分

本帖子是原文的葡萄牙语版本, 英语, “成功的 Git 分支模型“, 经作者正式授权, 文森特·德里森(C). 谢谢大家!

出于技术原因, 一些关键字是故意保存在英语. 我试图确保文本的独创性, 但我承认,我不得不作出调整,以促进理解我们的语言 (EN-US). 欢迎任何更正或改进翻译的建议.

介绍

这不是一个华盛顿邮报教如何使用Git. 如果这是你需要的, 我建议看看 手动做 Git. 展示如何执行软件版本控制的目标也不是我们的目标, 在这种情况下, 请参见 语义版本控制.

在这里,建议管理团队在软件版本控制方面的合作. 你知道当你有多个程序员 “搅拌” 在同一源代码中? 这对加快, 但它可以引起很多头痛 (损伤和重新工作) 如果没有控制. 防止一个开发人员覆盖另一个开发人员的工作,并确保逐步和有组织的开发, 最大限度地减少冲突并管理软件版本, 是,我们使用Git和 分支 跟随.

分支模型

在这篇文章中,我介绍了我在一些项目中使用的发展模式 (无论是在工作和私人) 约 1 几年前, 非常成功. 我想写它很久了, 但从未找到可用时间, 为止. 我不会谈论项目细节, 只关于战略 分支 和管理 释放.

此模型专门关注 Git 作为版本控制所有源代码的工具. (顺便一提, 如果你对Git感兴趣, 我们公司 吉特Prime, 新年 提供, 在真正的时间, 软件工程优化的一些惊人的数据分析)

为什么选择 git?

与集中式源代码管理系统相比,彻底讨论 Git 的利弊, 请参见Web. 有一个巨大的 “战争” 周围. 作为开发人员, 比起今天存在的所有其他工具,我更喜欢 Git. Git 无疑改变了开发人员思考 合并 或创建 分公司. 我来自经典世界 CVS/颠覆, 在哪里 合并/分支 这是你只是做不时的事情,它总是似乎有点吓人 (“谨防 合并, 他们咬你!”).

已经与 Git 这些操作 [合并/分支] 非常简单,代表了我们日常工作的主要部分之一, 相信. 举个例子, 在 CSV/颠覆, 分支合并 仅在后面的章节中首次讨论 (高级用户), 而在任何 关于 Git 的书, 这见于章节 3 (基本).

由于其简单性和重复性, 分支合并 不再害怕. 的确, 版本控制工具应有助于合并 并创建 分公司 比什么都重要.

不再说话, 让我们去开发模式. 我将在此处介绍的模型实质上只是每个团队成员为了达成托管软件开发过程而必须遵循的一组过程.

分散, 但集中

我们使用的存储库配置与 分支 由中央存储库组成. 请注意,此存储库仅 “采取作为” 中央 (因为 Git 是 DVCS [分布式版本控制系统], IE, 在技术层面,没有像中央存储库这样的). 我们将此存储库引用为 起源, 因为这个名字是所有 Git 用户都熟悉的.

每个开发人员 对于 起源. 但除了关系 推拉 对于集中式 [起源], 每个开发人员也可以拿起 [] 其他对的更改,形成子团队. 举个例子, 这对于与两个或多个开发人员一起处理一个新的伟大功能非常有用, 以前发送 [推动] 正在进行的工作 起源. 在上图中, 有爱丽丝和鲍勃的子团队, 爱丽丝和大卫, 克莱尔和大卫.

技术, 这意味着只有爱丽丝定义了一个远程Git叫鲍勃, 指向鲍勃的存储库, 反之亦然.

主要分支

在后台, 这种发展模式是深受现有模型的启发. 中央存储库有两个分支 [分支] 无限生命:

  • 主人
  • 发展

主分支起源 每个 Git 用户都应该熟悉. 平行于 主分支, 还有另一个 分公司发展.

考虑 原点/母版 作为主要分支的源代码 始终反映状态 生产就绪 [准备生产].

考虑 起源/发展 作为 分公司 主的源代码 始终反映状态,并在下一版本中提供最新开发更改. 有些人会称之为 “分公司 集成”. 这是最险恶的建筑发生的地方.

当源代码在 分支开发 达到一个稳定点,并准备被释放 [释放], 必须合并所有更改 [合并] 回到 主分支 然后用版本号标记 [释放]. 如何详细完成, 稍后将讨论.

所以, 每次合并更改时 [合并] 回到 主人, 生成新版本 [释放], 根据定义. 我们试图对此非常严格, 所以, 理论上, 我们甚至可以使用脚本 自动创建我们的应用程序,并发送到生产服务器,每当有一个 提交主人.

辅助分支

旁边的 分支 主要, 主人发展, 我们的开发模式使用各种 分支 支持协助团队成员之间的同步发展, 什么 1) 便于跟踪新功能 [特征], 2) 准备交付新版本 [释放] 和 3) 帮助您快速修复生产故障 [修复]. 与 分支 主要, 这些 分支 寿命短, 因为它们最终会被删除.

不同类型的 分支 [辅助] 我们可以使用, 是:

  • 功能分支
  • 释放分支
  • 修补程序分支

每个 分支 具有特定目的,受严格规则的约束, 因此, 分支 可能导致 分公司分支 必须合并 [合并] 他们的目标. 我们将看到他们每个人 [分支] 在瞬间.

从技术角度看, 这些 分支 不被视为 “特殊”. 每种类型 分公司 按我们使用它们的方式分类. 不管怎么说, 只是简单 分支 好老Git.

功能分支

[功能 = 功能/功能]

– 可以分支 [分公司] 从:
发展
– 它应该合并 [合并] 再次:
发展
– 任命公约 分公司:
什么, 除了 主人, 发展, 释放-*, 或 热修复-*

功能分支 (或有时称为 主题分支) 用于为即将发布或未来的版本开发新功能/功能. 开始开发 特征, 将嵌入此功能的目标版本在那个时候可能未知.

的本质 功能分支 是,它的存在,而 特征 正在开发中, 但最终它将被纳入 [合并] 回到 发展 (绝对添加新的 特征 到下一个 释放) 或丢弃 (在实验失败的情况下).

功能分支 通常只存在于存储库中 发展, 不在 起源.

创建要素分支

$ git 结帐 -B 我的功能发展
# Switched to a new branch "myfeature"

在开发中嵌入已完成的功能

特点, 新年 已完成可以合并[合并] 与 分支开发 肯定将它们添加到下一个 释放.

$ git 结帐开发
# 切换到分支"开发"
$ git 合并 ---我的功能 ff
# 更新 ea1b82a.05e9557
# (更改摘要)
# $ git 分支 -d 我的功能
# 已删除分支我的功能 (是 05e9557).
$ git 推送源开发

标志 –无 ff 导致混合 [合并] 始终创建新 提交, 即使合并可以执行与 快进 [Ff]. 这样可以防止有关存在 功能分支, 将所有 提交 已添加到 特征. 比较:

在后一种情况下 [从上图], 这是不可能看到从git的历史 提交 已在 特征; 您必须手动读取所有日志消息. 反转 特征 整个 (IE, 一组 提交), 这是一个真正的头痛在最后的情况下, 而这是很容易做到的,如果国旗 –无 ff 已使用.

是的, 这将创建一些更多的对象 提交 (空), 但收益远远高于成本.

释放分支

[发布 = 发布/交付/版本]

– 可以分支 [分公司] 从:
发展
– 它应该合并 [合并] 再次:
发展主人
– 任命公约 分公司:
释放-*

分支发布 帮助准备新的生产版本 [生产版本]. 他们让你把滴在最后一分钟,我. 另外, 他们允许轻微更正 错误 和定义 元数据 对于 释放 (版本号, 生成日期, 等). 通过在 释放分支, 的 发展分支 获得干净接收 特征 下一个大 释放 [版本].

创造新 释放分支 分支出 发展 是当 发展 已 (几乎) 反映新状态的预期状态 释放 [版本]. 所有 特征 候选人 释放 要建成必须纳入 [合并] 自 发展 在这一点上. 另一方面 特征 针对 释放 期货应该期待下一个 释放 [版本].

就在一开始 释放分支 下一个 释放 接收版本号 – 不是以前. 直到那一刻, 的 发展分支 反映了对 “下一个版本” [下一个版本], 但不清楚这是否 “下一个版本” 最终将 0.3 或 1.0, 直到 释放分支 已启动. 此决定是在 释放分支 并且由版本控制项目的规则执行 [建议看到约 “语义版本控制“].

创建发布分支

分支发布发展分支. 举个例子, 假设版本 1.1.5 是当前的生产版本,我们有大量的 释放 来. 的状态 发展 已准备就绪 “下一个版本” [下一个版本] 我们决定,这将成为 1.2 (而不是 1.1.6 或 2.0). 所以, 我们分支,并给予 释放分支 反映新版本号的名称:

$ git 结帐 -B 版本-1.2 发展
# Switched to a new branch "release-1.2"
$ ./-版本.Sh 1.2
# 已成功修改文件, 版本撞到 1.2.
$ git 提交 --M "Bumped version number to 1.2"
# [版本-1.2 74d9424] 凹凸版本号到 1.2
# 1 已更改的文件, 1 插入(+), 1 删除(-)

创建新 分公司 并访问它, 我们撞到版本号. 这里, bump-version.sh 是一个外壳脚本,它更改了一些工作副本文件以反映新版本. (这可以, 答案是肯定的, 是手动更改 – 关键是某些文件会更改。) 所以, 是 提交 修改的版本号.

此新 分公司 可能在那里存在一段时间, 直到 释放 绝对是推出. 在此期间, 可以在此应用错误修复 分公司 (而不是 发展分支). 新增大 特征 这里是严格禁止的. 必须合并它们 [合并] 在 发展 和, 喜欢这个, 等待下一个大 释放.

完成发布分支

释放分支 准备成为一个真正的版本, 需要执行一些行动. 第一, 的 释放分支 合并为 主人 (因为每个 提交主人 根据定义是新版本, 记得). 然后, 这 提交主人 应标记,以方便将来引用此版本历史记录. 最后, 在 释放分支 需要合并 [合并] 再次为 发展, 使 释放 期货也包含这些错误修复.

Git 的前两个步骤:

$ git 签出主机
# 切换到分支"主"
$ git 合并 ---ff 版本-1.2
# 通过递归合并.
# (更改摘要)
$ git 标记 -1.2

释放 现已完成并标记为将来参考.

注意: 您还可以使用 -s 或 -u 标志 以加密方式对标记进行签名.

保持 在 释放分支, 我们需要把它们放回一起 发展. 无 Git:

$ git 结帐开发
# 切换到分支"开发"
$ git 合并 ---ff 版本-1.2
# 通过递归合并.
# (更改摘要)

此步骤可能导致合并冲突 (可能去, 一旦我们更改了版本号). 如果是, 修复并做 提交.

现在, 我们真的分手了, 的 释放分支 可以删除, 因为我们不再需要它了:

$ git 分支 -d 发布-1.2
# 已删除的分支版本-1.2 (是 ff452fe).

修补程序分支

– 可以分支 [分公司] 从:
主人
– 它应该合并 [合并] 再次:
发展主人
– 任命公约 分公司:
热修复-*

修补程序分支 非常类似于 释放分支, 因为它们也打算准备一个新的生产版本, 虽然计划外. 它们产生于生产版本出现不需要的状态后需要立即采取行动 [正在使用]. 当生产版本中发生严重错误时, 应立即解决, 然后 修补程序分支 可以从标记派生,该标记在 主分支.

其实质是团队成员的工作 (在 发展分支) 可以继续, 而其他人正在准备生产故障的快速修复.

创建修补程序分支

修补程序分支主分支. 举个例子, 假设版本 1.2 是当前版本的生产版本运行,并呈现问题,由于严重的错误. 中的更改 发展 保持仍然不稳定. 然后,我们可以分支 修补程序分支 并开始解决问题:

$ git 结帐 -b 热固-1.2.1 主人
# Switched to a new branch "hotfix-1.2.1"
$ ./-版本.Sh 1.2.1
# 已成功修改文件, 版本撞到 1.2.1.
$ git 提交 --M "Bumped version number to 1.2.1"
# [热修复-1.2.1 41e61bb] 凹凸版本号到 1.2.1
# 1 已更改的文件, 1 插入(+), 1 删除(-)

不要忘记在分支后更改版本号!

然后, 更正错误,并使 提交 一个或多个修正 提交 单独.

$ git 提交 -M "Fixed severe production problem"
# [热固-1.2.1 abbe5d6] 修复了严重的生产问题
# 5 已更改的文件, 32 插入(+), 17 删除(-)

完成修补程序分支

完成后, 的 错误修复 需要合并回 主人, 但它也需要再次纳入 发展, 为了确保 错误修复 也包含在下一个版本. 这与 释放分支 已完成.

第一, 更新 主人 并标记 释放 [标志着夏天]:

$ git 签出主机
# 切换到分支"主"
$ git 合并 ---修补程序 ff-1.2.1
# 通过递归合并.
# (更改摘要)
$ git 标记 -的 1.2.1

注意: 您还可以使用 -s 或 -u 标志 以加密方式对标记进行签名.

然后, 包括 错误修复发展 还:

$ git 结帐开发
# 切换到分支"开发"
$ git 合并 ---修补程序 ff-1.2.1
# 通过递归合并.
# (更改摘要)

这里唯一的例外是, 当有一个 释放分支 正在进行中, 的变化 修复 需要为此合并 释放分支, 而不是 发展. 合并 错误修复释放分支 将导致 错误修复 合并到 发展 还, 当 释放分支 已完成. (如果工作在 发展 立即要求这 错误修复 不能等到 释放分支 已完成, 您可以安全地合并 错误修复德韦奥普 也。)

最后, 删除 分公司 临时:

$ git 分支 -修补程序 d-1.2.1
# 已删除的分支修补程序-1.2.1 (是 abbe5d6).

总结

虽然在这个分支模型中没有什么真正特别的, 在邮报的开头的数字可以非常有助于我们的项目. 它显示了一个易于理解的心理模型,并允许团队成员对 分支释放.

原始帖子的博客上提供了该图的高质量 PDF 版本: http://nvie.com/posts/a-successful-git-branching-model/ [或以下下载链接]. 继续,并把它放在墙上,以获得快速参考在任何时候.

总点击数: 7507

略论 “Git 中成功的分支模型

  1. 迪夫森出生 说︰:

    下午好, 知道Git最初是由Linux系统开发的,但当谈到可移植性时, 我不知道如果git运行在窗口MSIS和POSIX??

留言

您的电子邮件地址将不会发布. 与标记必填的字段 *