分支和发布

最新推荐文章于 2025-08-01 09:16:57 发布
翻译 最新推荐文章于 2025-08-01 09:16:57 发布 · 892 阅读 · 0

本文介绍了Android开源项目的维护方式及版本控制策略。通过代码行的概念来区分稳定的Android版本与实验性工作，确保了OEM厂商和其他设备制造商可以获取到官方的稳定版本。同时，还涉及到了上游工程的概念以及与之交互的方式。

Android 代码行

Android 开源项目维护一个完成的软件堆义务，被OEM移植和其它设备实施者（译者注：原词：implementors）运行在实际硬件。据此，我们维护一个编号"代码行"来明确的分开当前  Android 稳定版本从不稳定实验工作。

下面的图表描绘在一个 AOSP 管理代码和发布的概念等级。我们是指这些简单的作为"代码行"替代"分支"，因为在任何特定时刻，这些可能是多于一个分支现存一个特定"代码行"。具体例子当一个发布是缩减的，一些时候将变成一个新分支在 git，有些时候不是，基于需要的时刻。

code-line diagram

注意和解释

  • 一个发布对应一个 Android 平台的正式版本，例如 1.5，2.1，等等。通常来说，一个平台的发布对应一个 SdkVersion 域用在 AndroidManifest.xml 文件，并且定义在源文件树的frameworks/base/api。

  • 一个上游工程是一个开源工程，从 Android 栈拉代码。这些包括明显的工程，例如 Linux 内核和 WebKit，但是随着时间的推移，我们迁移一些半自治 Android 工程(例如 Dalvik，Android SDK 工具，Bionic，等等)工作作为"上游"工程。通常，这些工程是在公共树开发完全。一些上游工程，发展是直接对上游工程自己做贡献。看上游工程细节。在这两种情况下，快照将被定期拉到发布。

  • 图表参考 "Eclair" 和 "FroYo"；然而，它们是简单的占位符，并且图表其实反映整体发布和分支战略。

  • 在所有的时间，一个发布代码行(可能其实包括多于 git 中的一个分支)被考虑称为一个特定 Android 平台版本唯一典范源代码。OEM 和其它群体构建设备将拉仅仅从一个发布分支。

  • 我们将设置"实验"代码行捕获改变从社区，所以它们能被迭代，并且对于稳定性的眼光。

  • 证明稳定的改变将终于被拉到一个发布分支。注意浙江仅仅应用到 bug 修复，应用改善，和其它不影响平台 API 的东西。

  • 必要的话，改变将被拉到发布分支从上游工程(包括 Android "上游"工程projects)。

  • 第 "n+1" 版(下一个框架和平台 API 的主要版本)将被开发由 Google 内部。看下面的细节。

  • 必要的话，改变将从上游被拉，发布，和实验分支到 Google 的私有分支。

  • 当下一个版本的平台 API 有稳定和充分测试，Google 将剪去下一个平台版本的发布。(这是特别的，参考一个新 SdkVersion。)这将也对应一个公共发布分支制作的内部代码行，和新的当前平台代码行。

  • 当一个新平台版本被剪去，一个对应实验代码行将被创建在相同时间。

关于私有代码行

以上的源管理战略包括一个 Google 将保持私有的代码行。原因是集中注意在当前 Android 的公共版本。

OEM 和其它设备构建自然想设备搭载最新版本的 Android。同样，应用开发者不想处理更多的现存严格必要的平台版本。与此同时，Google 保留 Android 战略方向的责任作为一个平台和一个产品。我们的途径是基于聚焦在一个小号码的旗舰设备主导特征，和 Android 有关的知非识产权保护的安全保护。

作为一个结果，Google 频繁藏有第三方的机密信息，并且我们必须避免从揭示敏感特征单元，我们已经抵押适当的保护。与此同时，这些是真的风险，这平台产生从有太多平台版本现存在当下。这些原因，我们有构造这个开源计划--包括第三方贡献--聚焦在目前公共稳定版本的 Android。"深度发展"在这平台的下一个版本将发生在私人，直到它已经变成官方发布。

我们承认许多贡献将不同意这个途径。我们尊重其他可能有一个不同看法；然而，这个途径我们感觉是最好的，并且这一个我们已经选择实施。


Git分支管理策略与发布流程及版本控制
polsnet的专栏
05-16 1338
通过合理使用主分支、功能分支、发布分支和热修复分支，可以实现代码的隔离、并行开发、稳定版本控制、快速问题修复和版本控制与发布准备。完成开发后，功能分支会合并回主分支。主分支（Main Branch）：主分支是项目的主要代码分支，用于存放稳定的、经过测试的代码。分支操作：使用git branch命令创建新的分支，使用git checkout命令切换分支，使用git merge命令合并分支。分支支持：Git鼓励频繁地创建和使用分支，支持轻松创建、切换、合并和删除分支，使并行开发和特性开发变得更加灵活和可控。
天工开物 #6 Git 分支管理与版本发布
Miracle
05-19 1153
Git 版本管理系统由 Linux 的作者 Linus Torvalds 于 2005 年创造，至今不到二十年。起初，Git 用于 Linux Kernel 的协同开发，用于替代不再提供免费许可的 BitKeeper 软件。随后，这一提供轻量级分支的分布式版本管理系统得到了开源开发者的广泛喜爱，在大量开源项目中投入使用。如今，Git 几乎是版本管理系统的同义词。Git 最大的创新就是轻量级的分支实...
git源码分支发布流程
bboyzhouda的博客
06-12 582
项目上线前开发流程: 1、从uat分支切出新分支 git checkout -b feature/branchName 2、开发完合并到uat分支 git merge feature/branchName 3、删除本地分支 git branch -d feature/branchName 项目上线： 1、uat分支合并到master分支 git merge uat 2、从master打好tag git tag -a v1....
Git分支发布
weixin_68503021的博客
09-12 1037
在Git Bash中自己的文件目录下输入第一个图片中框中的名字。第三个命令 检索改变的文件。第二个命令是发布到远程仓库。第一个命令是提交信息。第一个命令是创建分支。第二个命令是切换命令。
发布与分支
weixin_33682719的博客
01-24 440
首先来说一下发布的概念，发布的是什么呢，是故事（story）吗？不是，是特性（feature）！ 特性由一个或多个故事组成，单个故事可以验收，但是不能单独上线。比如当你做完了购物车的故事，是不能把单独把它上线的，因为你无法在购物车中进行结算。从用户体验的角度来说，这两个故事要么一起上，要么都不上。而且也不是一个特性完成了就可以立马上线的，比如圣诞大促的功...
Git之4-Git分支操作
casually的博客
09-25 563
此时如果要想将dev分支合并到主分支（master）中，此时就会产生冲突。线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支。以上就是手动解决文件中冲突的过程，之后只需要将工作区中的文件添加（add）到暂存区，然后再将暂存区中的文件，提交（commit）到本地仓库即可。用于部署生产环境的分支，确保master分支稳定性。当测试完成通过之后，合并master分支。注意：星号*在哪个分支前面，就表明当前处于哪个分支。
分支策略指南 | 发布分支、基于主干的分支、功能分支等常见分支策略利弊分析、版本控制工具Perforce Helix Core全新轻量级分支功能解析
weixin_49715102的博客
06-26 1463
而且，当您准备发布一个版本时，可能会考虑在主线（主干）之外创建一个版本分支，当然，前提是该版本功能分支中的所有功能都已合并（复制）到主线中。在最新的Perforce Helix Core版本中，备受期待的Sparse Streams功能通过新的轻量级分支功能将团队的分支策略提升到一个新的水平。但是，面对各种不同的分支策略（包括发布分支、基于主干的分支、功能分支等），如何确定哪一种分支策略更符合团队需求，是开发团队面临的一大问题。然后，当一切都稳定时，就可以将更改复制到父分支，并确保不会破坏父分支的稳定性。
git分支和标签
寒雪谷
03-31 1198
1. 分支管理 2. 标签 3. Git Flow
SVN分支机制和开发规范
05-14
三、 合并主干和分支 1、 主干合并分支 2、 分支合并主干 3、 合并发生冲突 情况1：标记冲突，稍后处理。 情况2：如果合并时，提示冲突时需要在线比对文件内容 四、 发布稳定版本到tags 五、 强制规范 六、 经验...
Jenkins选择分支发布Gitlab项目
Colinspace
03-17 3066
1、需要的插件 Git plugin Git Parameter Plugin Gitlab Plugin 2、Jenkins的Job配置 2.1、选择Job类型 为了后续的发布自由，默认都是选择 freestyle - 构建一个自由风格的项目![image.png](https://img-blog.csdnimg.cn/img_convert/968d06d72cf2077adc6f041550048a88.png#clientId=u83753ea7-08d8-4&crop=0&am.
主干发布和分支发布
dengguigu1986的博客
12-13 1317
一：主干发布 先说主干发布模式: 以SVN库为例,大致将库分为trunk, branch,tag三种,主线发布就是公司要发布某个产品的V1版本,之前大家都做会在SVN的trunk上做开发,等 trunk稳定了.开出一个分支B1,在B1分支上做V1版本的其它功能添加,bug修改等,并使用持续集成来验证B1的稳定性.直到V1版本达到要求, 可以对外发布,并且发布成功后,进行从branch到...
分支的使用以及发布说明
daxia_85的博客
02-01 1192
分支在VCS(版本控制系统)是一个重要的特性，对于开发人员来说合理的使用分支具有如下优点： 能够快速的进行代码的持续集成保证各功能／Bug修复的并行开发以及独立发布更易于从整体管理代码减少团队代码的冲突 下面会针对发布流程以及分支的相关内容进行逐个说明： 1. 从分支的角度了解开发／发布流程
Git:发布一个本地分支
希望我的博客，能帮上你解决学习中工作中所遇到的问题
07-06 1007
Git:发布一个本地分支
（jenkins系列三）多分支发布
m0_37298252的博客
01-21 749
下载插件 上篇博文中，我们只能发布指定的分支，实际情况下，一个项目的迭代过程会出现很多分支，甚至会频繁地更换测试环境中的分支版本，应对这种情况，需要我们能在构建发布的时候可以手动选择要发布的分支 jenkins可以借助插件git-parameter实现这个需求，首先到系统管理 -> 插件管理 -> 可选插件，搜索git-parameter并立即安装 配置参数 进入项目 -> 配置...
git分支及发布管理方式
Tiger的专栏
10-18 1261
如果git不加管理，可能出现枝节蔓生、四处开放的版本库。到处都是分支，完全看不出主干发展的脉络，造成下图的局面： 为了降低合并和版本管理的成本，团队引入一种值得借鉴的管理方式（link） 1.存在一条主分支（master）。所有用户可见的正式版本，都从master发布。主分支作为稳定的唯一代码库，不做任何开发使用。 拉取源：无需。 合并目标：无需。 修改：不允许。 生命期：持续。 2.存在一条开发分支（develop）。这个分支维护了当前开发中代码的主线，始终保持代码新于ma...
git 发布到远程分支
month_ss_815的博客
03-27 1859
git push提交报错：当前版本低于远程仓库版本。 解决办法（1）： 可以新建分支 git branch myself2 然后再git push -u origin myself2 ! [rejected] master -> master (non-fast-forward) hint: Updates were rejected becaus...
【Git】第十七节：Git 分支策略（Git Flow）—— 主流分支模型与标准化版本发布流程
silverclayz的技术分享
07-01 3237
Git Flow是一种标准化的Git分支管理策略，适用于需要规范版本发布的软件项目。它定义了五类核心分支：main（生产代码）、develop（开发主线）、feature/（功能开发）、release/（发布准备）和hotfix/*（紧急修复）。每种分支都有明确的创建、合并规则和生命周期。Git Flow通过feature分支开发新功能，release分支准备正式版本，hotfix分支处理线上问题，最终代码会合并到main和develop分支。
系统上线Release分支发布流程（不同公司流程规范不一样，仅供参考）
热门推荐
李文良的博客
09-09 16万+
前言：为了规范公司的版本管理，防止代码夹带现象出现，并向优秀公司学习版本管理流程。公司决定以小程序作为版本控制流程试点，这里也是以小程序为例！ 一、流程图 二、描述 1、开发将master的内容同步至fature分支上进行功能开发，当功能全部转测之后，开发将从fature分支创建release分支，完成之后，测试将创建分支的权限回收（通过将该release分支设置为保护分支。）以后开发每次需要向release分支提交内容时，需要找测试进行申请，测试将给开发临时权限（将该release分支从保护分支中解除
git分支的管理和发布规范
weixin_40466351的博客
08-01 946
分支名称分支介绍备注master（核心主分支）存放所有客户通用的主体功能代码，严格受保护，只能通过PR合并如果有多客户定制的情况下，不作发布分支release/client-{客户名}（客户定制分支）release/client-A、release/client-B，基于 master 创建，存放该客户独有的UI或业务流程代码。严格受保护,只能通过PR合并定制客户发布分支feature/功能描述。
帮我画一个开发分支和发布分支的示意图
最新发布
08-06
### 开发分支与发布分支的示意图 在 Git 的版本控制中，开发分支（`develop`）通常作为集成所有特性的主分支，用于团队成员协同开发新功能和修复缺陷。而发布分支（`release`）则是从开发分支创建出来的临时分支，用于准备发布新版本，通常包括最后的测试、文档更新和版本号调整等工作。 以下是一个典型的开发分支与发布分支的结构示意图： ``` A---B---C---D---E---F---G develop \ H---I---J release ``` - 每个字母代表一个提交节点，例如 `A` 是初始提交，`G` 是 `develop` 分支的最新提交，而 `J` 是 `release` 分支的最新提交。 - `develop` 分支是持续集成的主分支，所有新功能和修复都合并到该分支。 - `release` 分支是从 `develop` 分支的提交 `C` 处创建出来的，用于准备即将发布的版本[^1]。 ### 分支合并后的结构 当 `release` 分支的准备工作完成后，通常会将其合并回 `develop` 分支以及主分支（如 `main` 或 `master`），以确保所有变更都被正确集成并用于正式发布。合并后的结构如下： ``` A---B---C---D---E---F---G---K develop \ / H---I---J---* release ``` - 提交 `K` 是合并提交，表示 `release` 分支的内容已经被合并到 `develop` 分支。 - `*` 表示合并过程中 Git 自动生成的提交节点。 ### 分支操作流程示例 以下是一个典型的 Git 分支操作流程，展示如何创建、切换和合并 `release` 分支： ```bash # 查看当前分支 git branch # 创建并切换到 release 分支 git checkout -b release # 在 release 分支上进行提交 git add . git commit -m "Prepare for release" # 切换回 develop 分支 git checkout develop # 合并 release 分支到 develop git merge release ``` ### 版本发布流程 除了合并到 `develop` 分支，通常还需要将 `release` 分支合并到主分支（如 `main`），以确保正式发布的版本被正确记录： ```bash # 切换到主分支 git checkout main # 合并 release 分支到主分支 git merge release ``` ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值