Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 5 of 6

Branches and pull requests for agent changes

9 min

Listen to this lesson

0:00 / 8:13

Branches are cheap in git and expensive in ABAP. In a file-based project, each developer checks out a branch into a separate folder. In an ABAP system, there's one active version of each object, shared by everyone in that system. Switching a branch in abapGit doesn't give you a private copy; it rewrites the objects in the package for every user. That single fact shapes every branching strategy for ABAP.

Branching strategies that work in ABAP

StrategyHow it worksFits whenWatch out for
Short-lived branch per changePush the agent's change from CMD to a branch named after the transport; open a pull request against main; delete the branch after mergeOne shared dev system, classic transports; most teamsMain must reflect what is in CMD after merge, or diffs drift
Separate system or package per streamAgent experiments run in a sandbox system or a $ package; reviewed results are rebuilt or pulled into CMDExploratory agent work, prototypesTwo copies of truth until the result lands in CMD
abapGit Flow page (beta)Filtered git operations mirror branches and pull requests into and from transportsTeams willing to run a beta featureThe docs call it a beta feature and say filtered operations aren't real git

Branching strategies for ABAP given one active version per object.

Contoso chooses the first strategy. The agent works in CMD on objects recorded in a dedicated request; the developer pushes those objects to a branch such as cmdk900417-open-items; the pull request targets main, which mirrors the reviewed state of the package. Because CMD already contains the change before review, the review gate sits before transport release, not before the code enters CMD. Lesson 6 builds the full workflow.

One short-lived branch per transport; main only changes through an approved pull request.
The Sign-Off Table · thesignofftable.com/academy/sap-aid-204

What to look for in an ABAP diff

Reviewing agent-written ABAP isn't proofreading. A reviewer checks intent, scope and risk. The serialized XML files add noise; learn to skim them and read the .abap and CDS source closely.

  • Scope: every changed file belongs to the request in the title. Unrelated objects are a stop sign.
  • Authorization logic: removed or weakened AUTHORITY-CHECK statements, changes to CDS access controls or to RAP authorization methods.
  • Data access: new SELECT statements without a WHERE clause, missing ORDER BY where order matters, direct table updates that bypass the BO.
  • Hard-coded values: company codes, plants or user names typed into code (1710 belongs in configuration, not in a method).
  • Tests: new or changed ABAP Unit tests that really assert behavior, not tests rewritten to pass.
  • Metadata surprises: changed package, language or original system in an XML file.
  • Check results: ATC and ABAP Unit results attached to the pull request by the pipeline or by the developer.
Small, low riskOne reviewer; for example a message text or a test helper
Large, low riskSplit the change, or one reviewer plus a pipeline that runs ATC and ABAP Unit
Small, high riskTwo reviewers, one of them the object owner; authorization or pricing logic lives here
Large, high riskReject and re-scope; ask the agent for smaller, separate changes
Size and risk of the change decide how many reviewers it needs, and when to send it back.
The Sign-Off Table · thesignofftable.com/academy/sap-aid-204

Pull request rules for agent changes

  • Protect main: no direct pushes, merges only through approved pull requests.
  • Require two approvals for agent changes, at least one from the owner of the touched package (your git server's code-owner rules can enforce this).
  • Use a template: transport number, ticket, what the agent was asked to do, what was verified, test and ATC evidence, and the agent session identifier if your tooling records one.
  • Label agent-authored pull requests so you can measure them later (lesson 6 of sap-aid-301 uses those labels for metrics).
  • Never let the agent approve, merge or delete branches; its git credentials, if any, should allow pushing to feature branches only.

A pull request template turns these rules into a habit. Contoso's template for agent changes has six fields, and a reviewer can reject a pull request that leaves any of them empty:

  1. Request and ticket: the transport number (for example CMDK900417) and the change ticket.
  2. What the agent was asked to do: one or two sentences in plain language, not the full prompt.
  3. What a person verified: which behavior the developer checked by hand, in which client, with which data.
  4. Evidence: ATC result (no priority 1 or 2 findings), ABAP Unit result, and any test run in CMD.
  5. Out of scope: objects the agent touched but the developer reverted, so reviewers know they were seen.
  6. Session reference: the agent session identifier, if the tooling records one, for the audit trail.

What would you do?

An agent was asked to add a validation that blocks closing a core agreement with open items. Its pull request changes the behavior pool, a test class and, unexpectedly, the access control for <code>ZC_CMC_CoreAgreement</code>, where one condition was removed. All tests pass. What should the reviewer do?

Key points
  • One active version per object means a branch switch rewrites the package for everyone; use short-lived branches per transport.
  • Review scope, authorization logic, data access, hard-coded values, tests and metadata, not just syntax.
  • Protect main, require two approvals with an owner for agent changes, and label agent pull requests.
  • The abapGit Flow page is a beta feature; label it as such if you use it.

Check your understanding · not graded

Lesson check

  1. 1. Why are long-lived parallel branches hard to use inside one ABAP development system?

  2. 2. How does the abapGit documentation describe the abapGit Flow page?

  3. 3. An agent pull request touches authorization logic that wasn't in scope. What is the right response?

  4. 4. Which control stops an agent from merging its own changes?