总控开发分支维护.md
概述
- 目前石犀总控引擎软件系统中,只认为存在一条主线产品在往后演进,其中这个主线产品的发布即会对应发布分支,在多次发布后,即会产生多条发布分支,这就是主要的分支形态。
- 类似演示平台其实认为它是一个客户定制产品,每个客户定制产品和主线产品是同级关系,也就是说,假设客户定制产品和主线产品的发布频率完全一致的情况下,同一个组件的一个版本开发,将有多个发布分支在演进,如 release-v1.2.3 、zsj-release-v1.2.3。
- 注意总控、引擎的发布版本规则是不同的。
- 展望:当一个客户定制产品已经和主线产品异化太严重时,应该将属于它的 release 分支抽取独立为新组件。
概念
- 主分支(main):主分支应始终保持可部署状态。所有从主分支衍生的分支最终都应合并回主分支。
- 特性分支(feature branches):用于开发新功能。每个特性分支应只关注一个具体的功能或修复。
- 修复分支(fix branches):用于处理生产环境中的紧急问题。修复后,应该将更改合并回主分支和所有受影响的当前活动分支。
- 发布分支(release branches):用于准备即将发布的版本。在此分支上,可以进行最后的调整、测试和 bug 修复。
- 标签(tags):用于标记重要的开发里程碑,如新版本发布。
注意点
- 合并策略:在主分支和特性分支之间定期合并可以减少合并冲突。但应避免不必要的合并,因为它们可能带来问题而不是解决问题。
- 版本控制:给新版本打标签(tag)可以帮助团队更好地管理版本和历史。标签创建后不应更改,以保持历史的准确性。
- 分支生命周期:每个分支应有明确的创建和终结时间。长期存在的分支可能难以维护,容易产生过时的代码和合并冲突。
- 紧急修复:紧急修复应在专门的分支上进行,并尽快合并回主要分支。这有助于快速部署修复,同时保持主要分支的稳定。
- 代码审查:所有合并操作之前应有代码审查机制,确保新合并的代码符合质量标准。
- 测试:每次合并之后都应执行自动化测试,以保证新代码的加入不会破坏现有功能。
机制
创建版本
- 每个版本必须从 main 中签出
- 每个版本从 main 中签出后需要做此版本初始化维护工作,包括维护后需要和 main merge 一次,防止后续merge 难度太大,因为 main 保存的框架是多个 release 分支共同所有的,很有可能很多代码需要废弃掉或是需要新增工具库
优点
- 一致性基础:从
main
分支签出每个版本确保了所有版本都基于统一的代码基础,这有助于保持代码库的一致性。 - 稳定性:通常,
main
分支被视为最稳定的分支,用作创建新release
的基础可以减少引入未测试或不稳定代码的风险。 - 追踪简单:从
main
分支签出版本意味着所有版本的起点都是明确和统一的,便于追踪每个版本的变更。 - 集中管理:需要废弃或新增的代码和工具库的维护可以在
main
分支上进行,避免了在多个分支上重复相同的工作。
缺点
- 可能的初期不稳定:虽然
main
应该是稳定的,但如果存在频繁的合并,main
可能会暂时包含一些尚未完全验证的代码,这可能导致从main
签出的新版本需要更多的初期维护。 - 维护工作量:如果
main
分支经常接收来自多个release
分支的合并,那么每次从main
创建新版本时都可能需要进行显著的清理和初始化工作。 - 分支膨胀:如果每个新版本都从
main
签出,并且版本更新频繁,可能会导致大量的分支存在,增加了管理的复杂性。
结论
- 保持
main
的纯净:尽可能只在main
分支上进行稳定性和性能改进,而不是功能添加,这样新签出的版本就需要较少的初始化维护。 - 清晰的版本策略:确保有一个清晰的策略来决定何时和为什么需要创建新版本,避免不必要的版本创建。
- 自动化初始化工作:开发脚本或工具来自动化版本创建后的初始化工作,如代码清理、库更新等,以减轻人工负担。
- 详细的变更日志:维护一个详尽的变更日志,记录从上一个稳定点到当前
main
分支的所有变更,这样在签出新版本时,开发者可以迅速识别和处理那些需要被废弃或新增的代码。 - 代码审查和测试:在代码合并到
main
分支之前,实施严格的代码审查和测试流程,确保引入的变更都是稳定和可靠的。
定期合并
- 定一个周期,一个周期内每个 release 分支至少要和 main merge 一次,否则将导致 main 与众多分支太不一致
优点
保持一致性:定期合并有助于确保 main 分支与所有活跃的 release 分支保持一致,减少分支间的差异。
简化合并:频繁的合并可以减小每次合并的规模,理论上可以减少合并冲突的可能性。
及时发现问题:通过定期将更改合并回 main,可以更早地发现并解决集成问题。
流程规范化:这种策略强制实施了一个规范化的流程,要求团队成员按时完成任务,这有助于保持项目进度。
缺点
可能的过度集成:如果 release 分支还不稳定或者包含尚未准备好合并的功能,频繁的合并可能会导致 main 分支的不稳定。
合并负担:定期合并可能会增加团队的工作负担,特别是如果存在多个活跃的 release 分支时。
自动化测试的压力:频繁的合并需要强大的自动化测试支持,以确保不会引入新的错误。
过度的流程化:过度的流程化可能会限制某些情况下的灵活性,因为并非所有的工作流程都能适应这种定期合并的模式。
结论与展望
- 灵活应用:应该根据实际情况灵活应用这个规则。如果某个
release
分支包含的是一个大变更,可能需要特别的处理,而不是简单的定期合并。 - 强化自动化:增强自动化测试和构建流程,确保合并的过程尽可能无痛,并及时发现问题。
- 监控分支差异:监控不同分支之间的差异,确保没有太大的偏离。
- 及时通讯:确保团队成员之间有良好的沟通机制,合并时遇到的任何问题都应及时通知并寻求解决。
新版本启动前 tagging
优势
- 版本追踪:标签为版本提供了明确的锚点,使得在项目的生命周期中能够轻松地检出特定的发布版本。
- 回溯方便:如果在新版本发布之后发现问题,可以方便地回退到标签所指的提交进行 bug 修复。
- 文档记录:标签可以包括额外的发布信息,如版本号、发布日期等,提供了更丰富的历史信息。
- 构建和部署:自动化的构建和部署系统可以利用标签来触发特定版本的构建和部署。
- 非线性开发流程:在采用 Git 流或其他分支策略时,标签帮助维护了一个清晰的、非线性的开发历史。
- 热修复(Hotfixes):如果需要对特定版本进行热修复,可以从相应的标签签出一个热修复分支,修复后再合并回主分支。
定期同步 tagging
优势
- 维持代码同步:周期性地将
release
分支合并回main
可以保持各个分支间的同步,减少未来合并时的冲突概率。 - 固定集成点:这样做提供了一个固定的集成点,团队成员可以期待这些时间点,并准备他们的代码以确保合并时没有问题。
- 改进稳定性:通过定期的合并和标记,
main
分支始终保持最新且稳定的代码状态,确保了main
分支的代码质量。 - 简化版本追踪:每次合并后对
main
分支打标签,可以方便地跟踪各个周期的代码状态,这在识别问题和理解特定时间点的代码变更时特别有用。 - 自动化触发点:标签可以作为自动化构建和部署流程的触发点,比如当你在
main
上打上标签时,可以自动开始构建和部署到测试环境。 - 审计和合规性:在企业环境中,定期合并和标记可以提供审计跟踪,证明代码已经按照规定的流程进行了合并和测试。
- 快速回滚:如果新引入的代码导致问题,可以使用标签快速找到稳定状态的代码进行回滚。
- 里程碑文档化:对
main
分支的标记可以作为项目进度的里程碑,有助于文档化项目的发展历程。
缺点
- 过度合并:如果
release
分支还不稳定或包含未完成的特性,过度频繁的合并可能会向main
分支引入不稳定的代码。
事务和时机
范围
现设定有下面关于分支管理的事务,并在下面对每个事务执行的时机和注意事项进行说明
- 打标签:在每个重要的发行版或里程碑完成时打标签,比如完成一个稳定的开发周期或准备发布一个新版本。
- 创建分支:当开始新功能开发、预备新版本发布,或需要紧急修复时创建新的分支。
- 合并分支:功能完成且经过充分测试时,将特性分支合并到主分支;紧急修复完成后,立即合并到主分支和其他相关分支。
- 定期维护:定期评估现有分支,删除不再需要的分支,合并长时间未更新的分支,以保持代码库的整洁和可管理性。
- 紧急修复:一旦在生产环境中发现紧急问题,立即创建修复分支,开始修复工作,并按照紧急情况处理合并和部署。
时机
打标签(tagging)
main
- 启动一个新版本时先打 tag, tag content: init version $version
- 定期维护所有发布分支和 main 分支,一次整体维护完之后打 tag
图表和图像
方案一
%%{init: { 'logLevel': 'debug', 'theme': 'default' , 'themeVariables': {
'gitBranchLabel0': '#ffffff',
'gitBranchLabel1': '#ffffff',
'gitBranchLabel2': '#ffffff',
'gitBranchLabel3': '#ffffff',
'gitBranchLabel4': '#ffffff',
'gitBranchLabel5': '#ffffff',
'gitBranchLabel6': '#ffffff',
'gitBranchLabel7': '#ffffff',
'gitBranchLabel8': '#ffffff',
'gitBranchLabel9': '#ffffff'
} } }%%
gitGraph
# 初始化组件代码仓库
checkout main
commit
branch feat-init
commit id: "A1" type: NORMAL
commit id: "A2" type: NORMAL
commit id: "A3" type: NORMAL
checkout main
merge feat-init
# 启动一个新版本时先打 tag 方便随后切分支
commit id: "fix branch main timestamp1" tag: "init v1.2.3"
# 签新版本分支,从 main 中
branch release-v1.2.3
# 签版本分支后先进行新分支的维护,并与 main 进行一次初步合并
commit id: "v1.2.3 init"
checkout main
merge release-v1.2.3
checkout release-v1.2.3
# feat-v1.2.3-1, fix-v1.2.3-x 同时进行,一个修复 bug,一个开发新功能
branch feat-v1.2.3-1
commit id: "feat-v1.2.3-1 init"
# release-v1.2.3 开始修复 A 功能 bug
branch fix-v1.2.3-x
commit id: "fix-v1.2.3-x init"
commit id: "Fix A 1"
commit id: "Fix A 2"
commit id: "Fix A 3"
checkout feat-v1.2.3-1
# release-v1.2.3 开发 B 功能
commit id: "B1"
commit id: "B2"
commit id: "B3"
checkout release-v1.2.3
merge feat-v1.2.3-1
# release-v1.2.3 提交修复 A 功能 bug
merge fix-v1.2.3-x
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
commit id: "PeriodMerge $timestamp1" tag: "PeriodMerge $timestamp1"
checkout release-v1.2.3
# release-v1.2.3 开发 C 功能
branch feat-v1.2.3-2
commit id: "C1"
commit id: "C2"
commit id: "C3"
checkout release-v1.2.3
merge feat-v1.2.3-2
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
commit id: "PeriodMerge $timestamp2" tag: "PeriodMerge $timestamp2"
checkout release-v1.2.3
commit id: "something 1"
commit id: "something 2"
# release-v1.2.3 继续维护 ... 直到维护周期结束
# 启动一个新版本时先打 tag 方便随后切分支
checkout main
commit id: "fix branch main timestamp2" tag: "init v1.2.4"
# 签版本分支,从 main 中
branch release-v1.2.4
# 签版本分支后先进行新分支的维护,并与 main 进行一次初步合并
commit id: "v1.2.4 init"
checkout main
merge release-v1.2.4
checkout release-v1.2.4
# release-v1.2.4 开始开发新功能
branch feat-v1.2.4-1
commit id: "feat-v1.2.4-1 init"
commit id: "D1"
commit id: "D2"
commit id: "D3"
checkout release-v1.2.4
merge feat-v1.2.4-1
# 这时生产 release-v1.2.3 出现 A 功能 bug4
# 先紧急解决 release-v1.2.3 问题,验证完合并代码
checkout release-v1.2.3
branch fix-v1.2.3-y
commit id: "fix-v1.2.3-y init"
commit id: "Fix A 4 release-v1.2.3"
checkout release-v1.2.3
merge fix-v1.2.3-y
# 再解决现有其他分支问题,目前 main 和 release-v1.2.4 也有同样的问题,想办法将 main 和 release-v1.2.4 分支中 A bug4 解决
# 方案:(不一定是这个方案,具体问题具体选择方案解决)直接合并 release-v1.2.3 和 release-v1.2.4 main 代码
# 方案 一: main release-v1.2.3 release-v1.2.4 关于 A 功能代码相似度较高,就直接合并代码
# 方案 二: release-v1.2.3 main 代码相似度低,main release-v1.2.4 相似度高 这种情况用上面方案
# 方案 三: release-v1.2.3 main release-v1.2.4 相似度都低,都分别 commit,等定期维护时 merge 分别维护 A 功能代码
# 方案 四: release-v1.2.3 release-v1.2.4 相似度高,与 main 相似度低,release 之间 merge,main 单独维护 A 功能代码(甚至去掉 A 功能代码)
checkout main
merge release-v1.2.3
merge release-v1.2.4
# release-v1.2.4 继续开发功能 E
checkout release-v1.2.4
branch feat-v1.2.4-2
commit id: "feat-v1.2.4-2 init"
commit id: "E1"
commit id: "E2"
commit id: "E3"
checkout release-v1.2.4
merge feat-v1.2.4-2
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.4
commit id: "PeriodMerge $timestamp3" tag: "PeriodMerge $timestamp3"
# 切分支继续开发 release-v1.2.4
checkout release-v1.2.4
branch feat-v1.2.4-3
commit id: "feat-v1.2.4-3"
commit id: "D4"
commit id: "D5"
commit id: "D6"
checkout release-v1.2.4
merge feat-v1.2.4-3
commit id: "fix branch3 v1.2.3"
# 定期维护所有分支 release-v1.2.4 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
merge release-v1.2.4
commit id: "PeriodMerge $timestamp4" tag: "PeriodMerge$timestamp4"
# 启动一个新版本时先打 tag 方便随后切分支
commit id: "fix branch main $timestamp3" tag: "init v1.2.5"
# 签分支启动版本 release-v1.2.5
branch release-v1.2.5
commit id: "release-v1.2.5 init"
checkout main
merge release-v1.2.5
# release-v1.2.5 上开发 F 功能
branch feat-v1.2.5-1
commit id: "feat-v1.2.5-1 init"
commit id: "F1"
# ,,,
方案二
%%{init: { 'logLevel': 'debug', 'theme': 'default' , 'themeVariables': {
'gitBranchLabel0': '#ffffff',
'gitBranchLabel1': '#ffffff',
'gitBranchLabel2': '#ffffff',
'gitBranchLabel3': '#ffffff',
'gitBranchLabel4': '#ffffff',
'gitBranchLabel5': '#ffffff',
'gitBranchLabel6': '#ffffff',
'gitBranchLabel7': '#ffffff',
'gitBranchLabel8': '#ffffff',
'gitBranchLabel9': '#ffffff'
} } }%%
gitGraph
# 初始化组件代码仓库
checkout main
commit
branch feat-init
commit id: "A1" type: NORMAL
commit id: "A2" type: NORMAL
commit id: "A3" type: NORMAL
checkout main
merge feat-init
# 启动一个新版本时先打 tag 方便随后切分支
commit id: "fix branch main timestamp1" tag: "init v1.2.3"
# 签新版本分支,从 main 中
branch release-v1.2.3
# 签版本分支后先进行新分支的维护,并与 main 进行一次初步合并
commit id: "v1.2.3 init"
checkout main
merge release-v1.2.3
checkout release-v1.2.3
# feat-v1.2.3-1, fix-v1.2.3-x 同时进行,一个修复 bug,一个开发新功能
branch feat-v1.2.3-1
commit id: "feat-v1.2.3-1 init"
# release-v1.2.3 开始修复 A 功能 bug
branch fix-v1.2.3-x
commit id: "fix-v1.2.3-x init"
commit id: "Fix A 1"
commit id: "Fix A 2"
commit id: "Fix A 3"
checkout feat-v1.2.3-1
# release-v1.2.3 开发 B 功能
commit id: "B1"
commit id: "B2"
commit id: "B3"
checkout release-v1.2.3
merge feat-v1.2.3-1
# release-v1.2.3 提交修复 A 功能 bug
merge fix-v1.2.3-x
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
commit id: "PeriodMerge $timestamp1" tag: "PeriodMerge $timestamp1"
checkout release-v1.2.3
# release-v1.2.3 开发 C 功能
branch feat-v1.2.3-2
commit id: "C1"
commit id: "C2"
commit id: "C3"
checkout release-v1.2.3
merge feat-v1.2.3-2
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
commit id: "PeriodMerge $timestamp2" tag: "PeriodMerge $timestamp2"
checkout release-v1.2.3
commit id: "something 1"
commit id: "something 2"
# release-v1.2.3 继续维护 ... 直到维护周期结束
# 启动一个新版本时先打 tag 方便随后切分支
checkout main
commit id: "fix branch main timestamp2" tag: "init v1.2.4"
# 签版本分支,从 main 中
branch release-v1.2.4
# 签版本分支后先进行新分支的维护,并与 main 进行一次初步合并
commit id: "v1.2.4 init"
checkout main
merge release-v1.2.4
checkout release-v1.2.4
# release-v1.2.4 开始开发新功能
branch feat-v1.2.4-1
commit id: "feat-v1.2.4-1 init"
commit id: "D1"
commit id: "D2"
commit id: "D3"
checkout release-v1.2.4
merge feat-v1.2.4-1
# 这时生产 release-v1.2.3 出现 A 功能 bug4
# 先紧急解决 release-v1.2.3 问题,验证完合并代码
checkout release-v1.2.3
branch fix-v1.2.3-y
commit id: "fix-v1.2.3-y init"
commit id: "Fix A 4 release-v1.2.3"
checkout release-v1.2.3
merge fix-v1.2.3-y
# 再解决现有其他分支问题,目前 main 和 release-v1.2.4 也有同样的问题,想办法将 main 和 release-v1.2.4 分支中 A bug4 解决
# 方案:(不一定是这个方案,具体问题具体选择方案解决)先解决 main 问题,再合并到 release-v1.2.4
# 方案 一: main release-v1.2.3 release-v1.2.4 关于 A 功能代码相似度较高,就直接合并代码
# 方案 二: release-v1.2.3 main 代码相似度低,main release-v1.2.4 相似度高 这种情况用上面方案
# 方案 三: release-v1.2.3 main release-v1.2.4 相似度都低,都分别 commit,等定期维护时 merge 分别维护 A 功能代码
# 方案 四: release-v1.2.3 release-v1.2.4 相似度高,与 main 相似度低,release 之间 merge,main 单独维护 A 功能代码(甚至去掉 A 功能代码)
checkout main
branch fix-main-A-4
commit id: "fix-main-A-4 init"
commit id: "Fix A 4 main"
checkout main
merge fix-main-A-4
merge release-v1.2.4
# release-v1.2.4 继续开发功能 E
checkout release-v1.2.4
branch feat-v1.2.4-2
commit id: "feat-v1.2.4-2 init"
commit id: "E1"
commit id: "E2"
commit id: "E3"
checkout release-v1.2.4
merge feat-v1.2.4-2
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.4
commit id: "PeriodMerge $timestamp3" tag: "PeriodMerge $timestamp3"
# 切分支继续开发 release-v1.2.4
checkout release-v1.2.4
branch feat-v1.2.4-3
commit id: "feat-v1.2.4-3"
commit id: "D4"
commit id: "D5"
commit id: "D6"
checkout release-v1.2.4
merge feat-v1.2.4-3
commit id: "fix branch3 v1.2.3"
# 定期维护所有分支 release-v1.2.4 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
merge release-v1.2.4
commit id: "PeriodMerge $timestamp4" tag: "PeriodMerge$timestamp4"
# 启动一个新版本时先打 tag 方便随后切分支
commit id: "fix branch main $timestamp3" tag: "init v1.2.5"
# 签分支启动版本 release-v1.2.5
branch release-v1.2.5
commit id: "release-v1.2.5 init"
checkout main
merge release-v1.2.5
# release-v1.2.5 上开发 F 功能
branch feat-v1.2.5-1
commit id: "feat-v1.2.5-1 init"
commit id: "F1"
# ,,,
方案三
%%{init: { 'logLevel': 'debug', 'theme': 'default' , 'themeVariables': {
'gitBranchLabel0': '#ffffff',
'gitBranchLabel1': '#ffffff',
'gitBranchLabel2': '#ffffff',
'gitBranchLabel3': '#ffffff',
'gitBranchLabel4': '#ffffff',
'gitBranchLabel5': '#ffffff',
'gitBranchLabel6': '#ffffff',
'gitBranchLabel7': '#ffffff',
'gitBranchLabel8': '#ffffff',
'gitBranchLabel9': '#ffffff'
} } }%%
gitGraph
# 初始化组件代码仓库
checkout main
commit
branch feat-init
commit id: "A1" type: NORMAL
commit id: "A2" type: NORMAL
commit id: "A3" type: NORMAL
checkout main
merge feat-init
# 启动一个新版本时先打 tag 方便随后切分支
commit id: "fix branch main timestamp1" tag: "init v1.2.3"
# 签新版本分支,从 main 中
branch release-v1.2.3
# 签版本分支后先进行新分支的维护,并与 main 进行一次初步合并
commit id: "v1.2.3 init"
checkout main
merge release-v1.2.3
checkout release-v1.2.3
# feat-v1.2.3-1, fix-v1.2.3-x 同时进行,一个修复 bug,一个开发新功能
branch feat-v1.2.3-1
commit id: "feat-v1.2.3-1 init"
# release-v1.2.3 开始修复 A 功能 bug
branch fix-v1.2.3-x
commit id: "fix-v1.2.3-x init"
commit id: "Fix A 1"
commit id: "Fix A 2"
commit id: "Fix A 3"
checkout feat-v1.2.3-1
# release-v1.2.3 开发 B 功能
commit id: "B1"
commit id: "B2"
commit id: "B3"
checkout release-v1.2.3
merge feat-v1.2.3-1
# release-v1.2.3 提交修复 A 功能 bug
merge fix-v1.2.3-x
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
commit id: "PeriodMerge $timestamp1" tag: "PeriodMerge $timestamp1"
checkout release-v1.2.3
# release-v1.2.3 开发 C 功能
branch feat-v1.2.3-2
commit id: "C1"
commit id: "C2"
commit id: "C3"
checkout release-v1.2.3
merge feat-v1.2.3-2
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
commit id: "PeriodMerge $timestamp2" tag: "PeriodMerge $timestamp2"
checkout release-v1.2.3
commit id: "something 1"
commit id: "something 2"
# release-v1.2.3 继续维护 ... 直到维护周期结束
# 启动一个新版本时先打 tag 方便随后切分支
checkout main
commit id: "fix branch main timestamp2" tag: "init v1.2.4"
# 签版本分支,从 main 中
branch release-v1.2.4
# 签版本分支后先进行新分支的维护,并与 main 进行一次初步合并
commit id: "v1.2.4 init"
checkout main
merge release-v1.2.4
checkout release-v1.2.4
# release-v1.2.4 开始开发新功能
branch feat-v1.2.4-1
commit id: "feat-v1.2.4-1 init"
commit id: "D1"
commit id: "D2"
commit id: "D3"
checkout release-v1.2.4
merge feat-v1.2.4-1
# 这时生产 release-v1.2.3 出现 A 功能 bug4
# 先紧急解决 release-v1.2.3 问题,验证完合并代码
checkout release-v1.2.3
branch fix-v1.2.3-y
commit id: "fix-v1.2.3-y init"
commit id: "Fix A 4 release-v1.2.3"
checkout release-v1.2.3
merge fix-v1.2.3-y
# 再解决现有其他分支问题,目前 main 和 release-v1.2.4 也有同样的问题,想办法将 main 和 release-v1.2.4 分支中 A bug4 解决
# 方案:(不一定是这个方案,具体问题具体选择方案解决)分别 commit,定期维护时维护 A 功能代码合并
# 方案 一: main release-v1.2.3 release-v1.2.4 关于 A 功能代码相似度较高,就直接合并代码
# 方案 二: release-v1.2.3 main 代码相似度低,main release-v1.2.4 相似度高 这种情况用上面方案
# 方案 三: release-v1.2.3 main release-v1.2.4 相似度都低,都分别 commit,等定期维护时 merge 分别维护 A 功能代码
# 方案 四: release-v1.2.3 release-v1.2.4 相似度高,与 main 相似度低,release 之间 merge,main 单独维护 A 功能代码(甚至去掉 A 功能代码)
checkout main
branch fix-main-A-4
commit id: "fix-main-A-4 init"
commit id: "Fix A 4 main"
checkout main
merge fix-main-A-4
checkout release-v1.2.4
branch fix-v1.2.4-x
commit id: "fix-v1.2.4-x init"
commit id: "Fix A 4 v1.2.4"
checkout release-v1.2.4
merge fix-v1.2.4-x
# release-v1.2.4 继续开发功能 E
checkout release-v1.2.4
branch feat-v1.2.4-2
commit id: "feat-v1.2.4-2 init"
commit id: "E1"
commit id: "E2"
commit id: "E3"
checkout release-v1.2.4
merge feat-v1.2.4-2
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.4
commit id: "PeriodMerge $timestamp3" tag: "PeriodMerge $timestamp3"
# 切分支继续开发 release-v1.2.4
checkout release-v1.2.4
branch feat-v1.2.4-3
commit id: "feat-v1.2.4-3"
commit id: "D4"
commit id: "D5"
commit id: "D6"
checkout release-v1.2.4
merge feat-v1.2.4-3
commit id: "fix branch3 v1.2.3"
# 定期维护所有分支 release-v1.2.4 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
merge release-v1.2.4
commit id: "PeriodMerge $timestamp4" tag: "PeriodMerge$timestamp4"
# 启动一个新版本时先打 tag 方便随后切分支
commit id: "fix branch main $timestamp3" tag: "init v1.2.5"
# 签分支启动版本 release-v1.2.5
branch release-v1.2.5
commit id: "release-v1.2.5 init"
checkout main
merge release-v1.2.5
# release-v1.2.5 上开发 F 功能
branch feat-v1.2.5-1
commit id: "feat-v1.2.5-1 init"
commit id: "F1"
# ,,,
方案四
%%{init: { 'logLevel': 'debug', 'theme': 'default' , 'themeVariables': {
'gitBranchLabel0': '#ffffff',
'gitBranchLabel1': '#ffffff',
'gitBranchLabel2': '#ffffff',
'gitBranchLabel3': '#ffffff',
'gitBranchLabel4': '#ffffff',
'gitBranchLabel5': '#ffffff',
'gitBranchLabel6': '#ffffff',
'gitBranchLabel7': '#ffffff',
'gitBranchLabel8': '#ffffff',
'gitBranchLabel9': '#ffffff'
} } }%%
gitGraph
# 初始化组件代码仓库
checkout main
commit
branch feat-init
commit id: "A1" type: NORMAL
commit id: "A2" type: NORMAL
commit id: "A3" type: NORMAL
checkout main
merge feat-init
# 启动一个新版本时先打 tag 方便随后切分支
commit id: "fix branch main timestamp1" tag: "init v1.2.3"
# 签新版本分支,从 main 中
branch release-v1.2.3
# 签版本分支后先进行新分支的维护,并与 main 进行一次初步合并
commit id: "v1.2.3 init"
checkout main
merge release-v1.2.3
checkout release-v1.2.3
# feat-v1.2.3-1, fix-v1.2.3-x 同时进行,一个修复 bug,一个开发新功能
branch feat-v1.2.3-1
commit id: "feat-v1.2.3-1 init"
# release-v1.2.3 开始修复 A 功能 bug
branch fix-v1.2.3-x
commit id: "fix-v1.2.3-x init"
commit id: "Fix A 1"
commit id: "Fix A 2"
commit id: "Fix A 3"
checkout feat-v1.2.3-1
# release-v1.2.3 开发 B 功能
commit id: "B1"
commit id: "B2"
commit id: "B3"
checkout release-v1.2.3
merge feat-v1.2.3-1
# release-v1.2.3 提交修复 A 功能 bug
merge fix-v1.2.3-x
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
commit id: "PeriodMerge $timestamp1" tag: "PeriodMerge $timestamp1"
checkout release-v1.2.3
# release-v1.2.3 开发 C 功能
branch feat-v1.2.3-2
commit id: "C1"
commit id: "C2"
commit id: "C3"
checkout release-v1.2.3
merge feat-v1.2.3-2
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
commit id: "PeriodMerge $timestamp2" tag: "PeriodMerge $timestamp2"
checkout release-v1.2.3
commit id: "something 1"
commit id: "something 2"
# release-v1.2.3 继续维护 ... 直到维护周期结束
# 启动一个新版本时先打 tag 方便随后切分支
checkout main
commit id: "fix branch main timestamp2" tag: "init v1.2.4"
# 签版本分支,从 main 中
branch release-v1.2.4
# 签版本分支后先进行新分支的维护,并与 main 进行一次初步合并
commit id: "v1.2.4 init"
checkout main
merge release-v1.2.4
checkout release-v1.2.4
# release-v1.2.4 开始开发新功能
branch feat-v1.2.4-1
commit id: "feat-v1.2.4-1 init"
commit id: "D1"
commit id: "D2"
commit id: "D3"
checkout release-v1.2.4
merge feat-v1.2.4-1
# 这时生产 release-v1.2.3 出现 A 功能 bug4
# 先紧急解决 release-v1.2.3 问题,验证完合并代码
checkout release-v1.2.3
branch fix-v1.2.3-y
commit id: "fix-v1.2.3-y init"
commit id: "Fix A 4 release-v1.2.3"
checkout release-v1.2.3
merge fix-v1.2.3-y
# 再解决现有其他分支问题,目前 main 和 release-v1.2.4 也有同样的问题,想办法将 main 和 release-v1.2.4 分支中 A bug4 解决
# 方案:(不一定是这个方案,具体问题具体选择方案解决)合并 release-v1.2.3 和 release-v1.2.4, main 单独解决,定期维护时再解决部分冲突
# 方案 一: main release-v1.2.3 release-v1.2.4 关于 A 功能代码相似度较高,就直接合并代码
# 方案 二: release-v1.2.3 main 代码相似度低,main release-v1.2.4 相似度高 这种情况用上面方案
# 方案 三: release-v1.2.3 main release-v1.2.4 相似度都低,都分别 commit,等定期维护时 merge 分别维护 A 功能代码
# 方案 四: release-v1.2.3 release-v1.2.4 相似度高,与 main 相似度低,release 之间 merge,main 单独维护 A 功能代码(甚至去掉 A 功能代码)
checkout release-v1.2.4
merge release-v1.2.3
checkout main
branch fix-main-A-4
commit id: "fix-main-A-4 init"
commit id: "Fix A 4 main"
checkout main
merge fix-main-A-4
# release-v1.2.4 继续开发功能 E
checkout release-v1.2.4
branch feat-v1.2.4-2
commit id: "feat-v1.2.4-2 init"
commit id: "E1"
commit id: "E2"
commit id: "E3"
checkout release-v1.2.4
merge feat-v1.2.4-2
# 定期维护 release-v1.2.3 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.4
commit id: "PeriodMerge $timestamp3" tag: "PeriodMerge $timestamp3"
# 切分支继续开发 release-v1.2.4
checkout release-v1.2.4
branch feat-v1.2.4-3
commit id: "feat-v1.2.4-3"
commit id: "D4"
commit id: "D5"
commit id: "D6"
checkout release-v1.2.4
merge feat-v1.2.4-3
commit id: "fix branch3 v1.2.3"
# 定期维护所有分支 release-v1.2.4 和 main 的关系,进行一次 merge
checkout main
merge release-v1.2.3
merge release-v1.2.4
commit id: "PeriodMerge $timestamp4" tag: "PeriodMerge$timestamp4"
# 启动一个新版本时先打 tag 方便随后切分支
commit id: "fix branch main $timestamp3" tag: "init v1.2.5"
# 签分支启动版本 release-v1.2.5
branch release-v1.2.5
commit id: "release-v1.2.5 init"
checkout main
merge release-v1.2.5
# release-v1.2.5 上开发 F 功能
branch feat-v1.2.5-1
commit id: "feat-v1.2.5-1 init"
commit id: "F1"
# ,,,
总控开发分支维护.md
https://abrance.github.io/2023/11/09/project/sr/总控开发分支维护/