★ FEATURED ARTICLE 1. 为什么你需要关心 gCTS 里的分支管理先说个背景。我自己在 SAP 项目里泡了十几年从最早用CTS做传输到后来项目全面转向gCTS说实话刚开始我是有点抵触的。毕竟在ABAP世界里旧的传输体系虽然笨重但大家都熟出了问题也好找资料。但项目一旦做大了特别是多团队并行开发、多版本同时维护的时候传统CTS那种“一条请求链走到底”的模式就非常吃力你要么把环境锁死要么忍受频繁的传输冲突要么靠一堆补丁请求把系统搞得千疮百孔。后来我们决定在 Manage Software Components 里真正把 gCTS 用起来其中一个核心动作就是在gCTS管理软件组件时创建分支。这一步看起来简单但它是整个“分支化开发”的基石。没有分支你没法做真正的并行开发没有分支你没法在同一个组件里同时维护开发版、测试版和热修复版没有分支你的发布流程永远是“排队上车”。这篇博文我只讲一件事怎么在 SAP ABAP gCTS 里基于 Manage Software Components 创建分支。但我会把这件事背后的逻辑、准备、操作、坑、以及分支之后怎么维护全部摊开来讲。适合谁看刚从CTS迁到gCTS的ABAP顾问、负责SAP开发环境治理的basis同事以及被领导要求“尽快用上gCTS”但还没摸清门道的开发负责人。我保证这不是一篇照着SAP Help翻译的操作手册。是我自己在我们项目里真实操作过、踩过坑、并且最终跑通全流程的实战记录。2. 工具选型与前置准备gCTS 到底解决什么问题2.1 为什么从 CTS 迁到 gCTS先花点篇幅说清楚 gCTS 是什么以及它解决了什么。因为如果你不理解“为什么”直接照着操作步骤点大概率会在某个环节卡住而且根本不知道为什么卡住。gCTSgit-based CTS本质上是把 ABAP 的传输请求和 Git 仓库做了绑定。你在ABAP里做的传输请求不再像传统方式那样用一个物理的 transport buffer 去推而是先提交到本地的 Git 仓库然后通过 Git 的 push / pull 流程在不同系统之间同步。这和传统 CTS 的差别非常大。传统 CTS 是“集中式、单链路、顺序传递”的而 gCTS 是“分布式、多分支、灵活合并”的。举个例子传统方式下如果开发系统里同时有10个人在开发大家都在往同一个 transport request 里塞对象那么测试系统就只能收到一坨完整的状态很难单独抽出某几个人的改动去测试。gCTS 下每个人或每个团队可以基于自己的分支工作推送代码到对应环境的仓库分支测试系统可以拉取指定的分支完全按需集成。还有一点gCTS 的底层仓库是真正的 Git 仓库这意味着你可以用 Git 的所有能力分支、标签、历史回滚、代码评审、CI/CD集成。这不是某个第三方工具套壳是 SAP 官方把 Git 能力内建到了 ABAP 开发环境里。2.2 创建分支前必须确认的三件事我在项目里见过太多人连前置条件都没检查就急着去点“Create Branch”结果自然是一堆报错。创建分支前我建议你先自查三件事第一你的系统版本是否支持 gCTS 分支功能。gCTS 本身从 S/4HANA 1709 就开始有了但分支管理的完整支持是后加的。如果你用的是老版本界面可能会不一样甚至根本没有“Create Branch”这个按钮。我做验证用的是 S/4HANA 2020分支功能完整如果你比这个版本老建议先去翻一下对应版本的 Release Notes。第二软件组件Software Component是否已经启用 gCTS 管理。这一步容易被忽略。gCTS 和传统传输不是对立的同一个系统里可以同时存在“传统CTS管理的组件”和“gCTS管理的组件”你必须在 Manage Software Components 里先把某个组件设为 gCTS 管理。如果组件还是传统模式你在创建分支时会找不到对应的 Git 仓库。第三GIT 仓库配置是否正确。gCTS 需要一个中心化的 Git 服务器比如 GitHub Enterprise、GitLab 或 SAP 自带的本地 Git 仓库且 ABAP 系统必须能访问到这个服务器。很多新手栽在这里ABAP 系统是内网Git 服务器在外网或者需要走代理导致 push/pull 一直失败。分支的操作本身是本地操作但后续的 push 是远程的所以网络和认证配置这一步不能省。对照这三点自查完再继续往下走你会轻松很多。3. 实操前置Manage Software Components 里的三个关键配置创建分支不是一个孤立动作它依赖三个前置配置。下面我把这三个配置逐个拆开讲清楚每个配置在哪、怎么填、以及常见错误。3.1 配置 Git 仓库凭据在 SAP GUI 里进入事务码SICF找到/sap/bc/git/相关节点激活相应的服务。这一步很多人容易漏因为 SICF 服务默认可能是未激活的。在系统里启用这个服务才能让 ABAP 与 Git 仓库正常通信。然后需要在SM30维护视图/GIT/GIT_CUSTOMIZE里面填 Git 仓库的 URL、认证方式、分支映射等信息。这个视图是 gCTS 的核心配置几乎所有 Git 层面的连接都在这里定义。认证这里我提醒一句如果你用的是 HTTP/HTTPS 协议认证方式可以用用户名密码也可以配 token。SAP 对 token 的支持很好我建议优先用 token原因很简单——token 可以设过期时间可以按仓库授权不需要把你的 AD 密码明文存放在配置里。如果是 SSH 方式需要用 JCo 和系统外部的密钥管理配置会繁琐一些一般企业内部用 HTTPS Token 就够了。3.2 将组件切换为 gCTS 管理这个动作在 Manage Software Components事务码MGMSOFCMP里做。你先在组件列表里找到目标组件进入组件详情查看当前的管理模式。如果是传统模式会显示“Transport”相关的选项。你要做一个“Switch to gCTS”的动作系统会提示你输入 Git 仓库并自动初始化仓库结构。这里有一个容易出错的地方切换后现有的传输请求不会自动迁移。我见过有项目切换前没做好传输请求收尾结果切换后一堆开发对象“凭空消失”了其实是留在了传统CTS那边但系统已经不看那边队列了。所以我们的经验是切换前必须先把所有 open 状态的传输请求妥善处理释放或回滚保证开发系统里没有未提交的对象再执行切换。3.3 确认分支可见性与默认分支组件切换为 gCTS 后系统会自动创建一个默认分支通常是master或/master。在 Manage Software Components 界面里你会看到一个分支列表里面至少有一行默认分支。这个默认分支非常重要。你在创建新分支时系统会问你要基于哪个分支创建。默认情况下所有人共享一个主线然后在上面拉自己的开发分支。你需要确认这个主线分支是可用的最好再从它拉一个初始分支作为“开发基线”而不是直接在 master 上做所有事。我个人的习惯是master永远代表“可发布状态”开发都在功能分支上进行测试通过后再合并回 master。这个习惯是从传统 Git 工作流延续过来的在 gCTS 里一样适用。4. 创建分支的核心操作基于 Manage Software Components 的完整流程这章是正文的重头戏我按实际操作的顺序把创建分支的每一步拆开附上关键参数和我的实战笔记。4.1 第1步进入 Manage Software Components在 SAP GUI 中调用事务码MGMSOFCMP或者通过 SAP Fiori 的 “Manage Software Components” 应用。系统会列出所有软件组件。这里有个小提示如果你在 Fiori 里打开操作界面更友好分支列表可以可视化展示。SAP GUI 里则更有“数据库操作”的感觉。两种方式最终的操作逻辑一致我用的是 SAP GUI 为主 Fiori 查看分支图谱为辅。进入组件列表后双击你要操作的目标组件。我演示用的组件名是/DMO/COMPONENT只是举例你换成自己项目里的真实组件名。4.2 第2步进入分支管理页面在组件详情界面里找到 “Branches” 标签页或者点击 “Go to Branch List” 按钮。系统会展示当前组件的所有分支以及每个分支对应的Local Commit和Remote Commit信息。这个界面是分支操作的“总控制台”。你可以在这里创建分支、切换分支、删除分支、以及查看每个分支的提交历史。我实测在分支数量多的时候界面上有一个搜索框可以按分支名过滤对仓库分支数量大的场景很有用。4.3 第3步点击创建分支并填写关键参数在分支管理页面中点击 “Create Branch” 按钮工具栏上通常是绿色的加号图标。系统会弹出一个小窗口你需要填以下关键参数Branch Name分支名称。这是必填项而且我强烈建议你一套统一的命名规范。比如feature/BM-10001-CustomerPrice、bugfix/BR-20306-SORelease、hotfix/RTC-8821。命名规范的意义在于当分支多起来之后你一眼就能看出这个分支是干嘛的、属于哪个需求或工单。我们项目里曾经有人随便起了个Test和John123最后根本没法溯源。Based on Branch基于哪个分支创建。默认是当前所在分支一般选master作为来源。除非你明确需要基于某个功能分支继续开发比如从一条已开发到一半的分支拉另一条做实验否则都从master拉新分支。Description分支描述。建议写上需求单号、负责人、创建日期。这个字段在分支列表里直接可见很方便。填写完毕后保存。系统会在后台执行以下动作创建本地分支对象执行一次 Git 的 checkout 操作切到新分支保持工作区内容一致因为是从 master 拉的所以内容和 master 相同。如果你填的分支名和已有分支重复系统会直接拒绝你。重复名是不允许的——即使你想“重新拉一个同名的分支来重置内容”系统也不允许你必须用一个新名字。4.4 第4步验证分支创建结果分支创建后不能直接关界面就走人。正确的验证姿势回到分支列表确认新分支出现在列表里确认当前系统的工作分支已经切到了新分支系统会高亮显示当前分支用事务码SE03或者gCTS相关的传输请求查看器确认一个新的传输请求已经挂到新分支下尝试做一个最简单的修改比如改一个注释释放传输请求然后推送确认这个修改是推到了新分支的远程仓库里而不是 master。我第一次做这个验证时没注意第4步结果后续所有开发都还在往 master 上推分支白建了。所以这个检查绝对不能省。4.5 从 Fiori 和 SAP GUI 操作的差异点SAP GUI 的操作路径MGMSOFCMP→ 双击组件 → Branches 标签页 → Create Branch。优点是字段清晰响应快适合批量管理缺点是分支关系只有列表没有图形化展示。Fiori 的操作路径打开 Manage Software Components 应用 → 选择组件 → 切到 Branches 页签 → Create Branch。优点是可以看到分支关系的可视化视图分支的 commit 状态一目了然适合给不熟悉 SAP GUI 的业务顾问使用。我个人建议如果你只是自己操作用 SAP GUI 效率更高如果你要给团队做演示或做分支评审用 Fiori 的视图更直观。两者操作到最后都写到同一个底层 Git 仓库没有任何冲突。5. 分支创建之后推送、拉取与日常使用的关键细节很多人以为创建完分支就结束了其实“创建分支”只是一个起点。真正让分支产生价值的是后续的开发流。5.1 分支下的开发流程Checkout → Change → Commit → Release → PushgCTS 的开发循环和传统 CTS 不一样。传统CTS是修改 → 添加到请求 → 释放请求 → 传输到目标系统。gCTS 是修改 → 添加到请求 → 提交到本地 Git → 推送到远程仓库。这个差异非常关键很多人刚上手时会糊涂。在 gCTS 里释放传输请求后对象不会自动进入目标系统。它只是进了本地 Git 历史你必须执行一次 Push 操作把本地提交推送到远程仓库目标系统比如测试机才能看到这次改动。那“目标系统怎么拿到你的改动”呢答案是目标系统也需要用 gCTS 管理同一个组件然后在目标系统里执行 Pull 操作从远程仓库把分支拉下来。这个拉取动作可以手动做也可以配成 CI/CD 自动化。这里有几个我们在实际项目中踩过的坑先给你预防针修改对象时尽量保证当前系统工作区是干净的。当你切换分支时如果你有未提交的修改系统会阻止切换或者要求你先处理干净。git stash 的概念在 gCTS 里也有类似的实现但逻辑复杂普通场景下不建议依赖它。Push 失败是最常见的故障。绝大多数情况是因为你本地有别人 push 过的提交你没有先 pull 合并直接 push 导致的冲突。此时必须先把远程改动 pull 下来解决冲突后再 push。分支删除之前务必确认该分支上所有传输请求都已释放并且已推送。如果删除了一个还有“未推送提交”的分支那些改动会变成孤儿提交虽然在 reflog 里还能找回来但恢复成本很高。5.2 分支合并让代码从开发线进入主线当一个功能分支开发完成并通过了测试接下来要做的是合并。合并的动作不发生在 SAP GUI 里而是在 Git 服务器端比如 GitLab 的 Merge Request / GitHub 的 Pull Request。也有团队直接在命令行里进行git merge然后推送再从 SAP 侧拉取。两种方式的差别在于用 GitLab/GitHub 的 Merge Request可以附加代码评审、CI 检查质量门禁更好。直接用git merge则更简单但缺少审查环节。我建议团队走 Merge Request 方式哪怕是最简单的改动也走一遍。理由很简单ABAP 开发者的编码习惯各不相同如果没有代码评审这个“安全网”一些明显的问题会直接溜进主线最后在测试环境爆发。合并时有一个关键策略合并回主线后开发分支的处理。合并已经生效这个功能分支就可以删除了。保持分支数量精简管理成本会低很多。6. 分支创建的进阶玩法与复杂场景处理来一点进阶的。除了“从 master 拉功能分支”这个基本玩法gCTS 的分支还能支持更复杂的场景下面说两个我们在真实项目里用到的。6.1 多版本并行维护支持旧版本上的紧急修复标准项目里常见这样的情形S/4HANA 的 Release 1 已经在生产环境运行团队同时在进行 Release 2 的开发。如果生产环境出现紧急问题需要基于 Release 1 的代码马上修复而此时 Release 2 的开发已经改动了大量代码传统的 CTS 方式会非常尴尬——你没法把 Release 2 里所有对象的改动全部挑出来再把 Release 1 的修复传过去。gCTS 的做法是在发布 Release 1 时给分支打个标签tag。当生产需要热修复时基于该 tag 创建一条hotfix/xxx分支改代码推送到远程再将这个修复分支 merge 回 Release 2 的开发主线。整个过程互不干扰改动精确控制。我们实际做过一次生产问题定位到某个功能模块的 3 个对象我们在 hotfix 分支上只改这 3 个对象通过 CI/CD 验证后直接部署。整个修复从发现问题到上线不到 2 小时这在传统传输模式下是不可想象的。6.2 多团队并行开发时的分支隔离和冲突管控当多个配套团队同时在一个组件下开发分支隔离能极大降低冲突。比如ABAP 端负责订单模块的团队用feature/order-module/BP-1001负责财务的团队用feature/finance-module/BP-1002。两个团队各自推送自己的分支测试环境按功能分支拉取。这个“按分支拉取”是关键。假设有 20 个分支同时在开发测试系统不能把 20 个分支全部拉下来那样会互相影响。标准做法是测试系统安装在主线分支上功能验证通过的分支合并回主线测试系统拉取主线更新即可如果有独立集成测试需求测试系统可以有多个“测试实例”每个实例拉一条分支。说白了分支隔离让你可以“干净地集成”而不是“所有人挤在一个锅里”。6.3 分支管理中的命名规范与权限控制分支多了以后没有规范会很混乱。我建议至少做以下两件事命名规范。统一前缀feature/、bugfix/、hotfix/、release/后面接需求号或工单号。这样通过分支列表就能快速筛选配合 GitLab/GitHub 的搜索功能找分支非常快。权限控制。谁可以创建分支谁可以合并到主线这需要一套规则。Git 服务器端可以配置开发者可以 push 自己的功能分支但只有 Maintainer 权限的人可以 merge 到 master。这些权限在 ABAP 端没有强制但在 Git 服务器端可以管理。不要裸奔式地放开所有权限。7. 常见问题与排查技巧实录下面这些问题是我们在实际应用 gCTS 分支过程中团队反映最多的几类。我整理成速查表并配上自己的排查建议。7.1 创建分支时提示“Branch already exists”或权限不足这两个问题其实是两类根源我分开说。如果提示分支已存在一种可能是真的重复了另一种可能是你在别的组件里也创建了同名的分支而底层 Git 仓库恰好是同一个。gCTS 里不同软件组件可以对应不同的 Git 仓库但如果配置时把两个组件指向了同一个仓库分支名就会冲突。如果提示权限不足检查用户在 Git 服务器上的权限。SAP GUI 里的报错只提示“permission denied”不会告诉你具体在哪个环节被拒。我们需要顺着 ABAP 到 Git 服务器整条链路去排查ABAP 系统中 SICF 服务是否有权限访问用户密码/Token 是否有效Git 服务器端该用户是否有该仓库的写权限网络层有没有防火墙或代理过滤。7.2 Push 失败rejected / non-fast-forward这个报错几乎每个人都会遇到。根本原因是远程仓库有本地没有的提交而这两个分支的历史线分叉了。解决方式很简单但注意别把 Git 搞乱在 ABAP 侧将你在本地做的修改目标分支切换到目标分支执行 Pull 操作选择合并策略合并远程分支到本地处理冲突执行 Push。在 ABAP 的 gCTS 界面里Pull 操作有一个“Strategy”选项默认是 merge也可以选择 rebase。团队刚上手时建议用 merge因为 rebase 需要本地历史“重写”处理不好容易造成混乱。7.3 分支切换后丢失修改部分人切换分支时提示有未提交修改但他们强行操作结果之前改的内容找不到了。这是最常见也最让我揪心的坑。gCTS 的机制是当你切换分支时若当前工作区存在未提交的修改系统会明确警告你。这个警告必须重视。解决方法是切换分支前先把当前分支上要保留的修改提交commit并推送再切走。或者先把修改传输请求释放掉也就是提交确认干净后再切换。如果不小心丢失了修改也不是完全没救。gCTS 底层还是 Git你可以去 Git 仓库里用 reflog 找回。但对于不熟悉 Git 的 ABAP 顾问来说操作起来会比较棘手所以最有效的做法还是一开始就纪律严明——改完一个需求及时提交分支不要“攒着”。7.4 快速问题排查速查表问题可能原因排查步骤创建分支时找不到组件组件未切换为 gCTS 管理检查是否已执行 “Switch to gCTS” 操作Push 一直转圈最终超时网络不通 / Git 服务器地址不可达ping 服务器、检查 SICF 服务状态Pull 之后对象“消失”拉取分支与当前开发分支内容不一致检查当前激活分支目标确认分支是否正确合并回 master 后测试系统没变化测试系统未执行 Pull登录目标系统gCTS 流程执行拉取分支删除后想恢复删除前未确认无未推送提交使用 Git reflog 在仓库端恢复此操作需要后台权限7.5 分支之前的备份意识我对所有搞 gCTS 的团队都会反复灌输一个观念分支不是备份机制commit 才是。开发过程中如果在一个功能分支上频繁修改和提交Git 历史就是你的完整流水任何时候都可以回退。传统 CTS 下我们做一个“备份”要单独导出请求麻烦且占资源gCTS 下每次 Commit 就是一个快照回退是瞬间的事。所以我自己在开发时有个习惯功能做到一个可编译、可测试的状态立即 commit 一次。不需要很大的改动一个 object 级别的修改也可以单独提交。宁可多 commit不要少 commit。7.6 和团队一起定一套分支协同规则上面很多问题本质上是“团队成员对分支的使用习惯不一致”造成的。我最后把规则定了下来发现接入期各种分支混乱的问题少了大半。这套规则包括master 分支只接受可发布的代码新功能必须从 master 拉分支开发不可直接在 master 修改所有合并必须通过 Git 服务器的 Merge Request 流程合并前必须保证无冲突且 CI 检查通过开发分支在合并后及时删除每次发布在 master 上打 tag 记录版本号。这套规则不是 SAP 官方强制的但实践下来非常好用。如果你想看效果可以从一个试点组件开始跑一个迭代周期再做评估。8. 最后说点实际操作中的个人体会gCTS 的分支管理功能给了我很大的信心。我最初担心它“不够 SAP 化”因为传统传输请求和 Git 完全是两套心理模型。但现在回头看gCTS 把 Git 的优秀机制带入 ABAP 世界是 SAP 在开发流程现代化上的关键一步。我在实际项目中还有一个体会是不要把 gCTS 当成“新的传输方式”去学而要当成“ABAP 开发代码管理的新底座”去重造你的工作流。如果你只是把老流程搬到新界面你感受不到分支带来的改变。只有当分支真正进入你的开发日常——拉一条分支改一个需求做完、推送、合并、删除——开发效率才会明显提升。对于刚开始用 gCTS 分支的团队我强烈建议从小范围试点开始选一个组件拉到独立分支跑完全部流程创建分支、开发、提交、推送、合并再做推广。亲眼看到这个流程比任何培训都有效。
阅读完成 · 觉得有帮助？
