Lesson 3 of 6
Pulling safely and avoiding common pitfalls
8 min
Listen to this lesson
Pushing is low risk: it copies objects out. Pulling is where damage happens, because pulling writes into the system. The abapGit documentation carries a security warning on its front page: abapGit will import, overwrite and change ABAP artifacts in the system in ways that might not be intended, so review all code in a remote repository before importing it into a target system. With agents in the loop, that warning covers two new cases: an agent that pulls a branch you didn't review, and a repository that contains text written to steer an agent.
What a pull actually does
- Creates objects that exist in the repository but not in the package.
- Overwrites objects whose files differ from the system version. SAP's documentation for its version notes that local changes that haven't been saved are overwritten by the import.
- Asks for a transport when the package is transportable. abapGit decides the request type from the package type: local $ packages need none; transportable Z packages need a transportable workbench request.
- May leave objects inactive. SAP's version imports objects inactive (where the type allows it) so activation can check them; you then activate.
- Stops on locks. Objects in open transport requests are locked; SAP says such requests must be released before the objects can change.
- Have you read the diff between the branch and the system?Yes → continue · No → stop; pulling unread code is the risk the docs warn about
- Is this a development system?Yes → continue · No → stop; abapGit pulls don't belong in CMQ or CMP
- Are any target objects in someone else's open request?No → continue · Yes → agree with the owner first or the pull will fail on locks
- Is the right branch selected?Yes → continue · No → switch; a pull from the wrong branch overwrites good code
- Do you have a transport for the pulled changes?Yes → pull and activate · No → create one so the change is traceable
Pitfalls that catch ABAP teams
| Pitfall | What happens | Prevention |
|---|---|---|
| Several repositories share one package | Objects appear in the wrong repository, or a pull overwrites another team's objects | One new package per repository, as the docs recommend |
| Objects "owned" by another system | Objects whose original system differs get mixed in | Local setting Only Local Objects limits selection to objects whose source system is the current system |
| Main language mismatch | Texts are created in the wrong language; abapGit can't change an object's main language | Set the main language once in .abapgit.xml; changing it needs uninstall and reinstall |
| Long package names with Prefix logic | Subpackage names exceed the 30-character limit and the pull fails | Shorter root package or a different folder logic |
| Missing namespaces or dependencies | Import or activation errors | Import namespaces and prerequisite objects first |
| Generated objects | Some objects are deliberately not exported because activation regenerates them | Expect them to be missing from the repository; don't "fix" it |
Common abapGit pitfalls drawn from the abapGit and SAP Help Portal documentation.
Settings that act as guardrails
- Write Protected (local setting): disables pulls, uninstall and branch switching so data can only flow from the system to the repository. The docs warn it only affects abapGit, not changes made in ADT or the Workbench.
- Code Inspector check variant: run a global Code Inspector or ATC check variant before staging. With Block Commit if Code Inspection has Errors, priority 1 and 2 findings prevent staging.
- Authorization exit: implement class
ZCL_ABAPGIT_AUTH_EXITwith interfaceZIF_ABAPGIT_AUTHto block actions such as uninstall or transport-to-branch for chosen users. - Normal SAP authorizations still apply: abapGit can't create or change objects your user isn't authorized for in S_DEVELOP, and transports follow S_TRANSPRT.
What would you do?
A developer asks a coding agent to "bring in the open-source date utility from the public repository" in CMD. The agent proposes creating an online repository on package <code>ZCMC_TOOLS</code>, which already holds 40 Contoso utility objects, and pulling the main branch. What do you do?
- Pulling creates, overwrites and changes objects; read the diff first and keep pulls in development systems.
- Use one new package per repository, Only Local Objects where needed, and set the main language once.
- Write Protected, a blocking check variant and the authorization exit are abapGit-side guardrails; SAP authorizations still apply.
- Treat repository content as untrusted input for agents; a person decides when to pull.
Check your understanding · not graded
Lesson check
1. What does the abapGit Write Protected setting do?
2. A pull fails because objects are locked. What is the most likely cause?
3. What happens with Block Commit if Code Inspection has Errors enabled?
4. Why should an agent not be allowed to run abapGit pulls on its own?