Shrikrushna Kulkarni · SAP ABAP/RAP Developer · Jun 16th 2026
Table of Contents
- Why gCTS?
- Prerequisites
- Create Your GitHub Repository and Personal Access Token
- Create a Software Component (SAP-side)
- Clone the Repository to Your SAP System
- Create ABAP Package and Link to Software Component
- Configure Repository Parameters
- Develop, Release, and Verify Your First Commit
- Deploy to QAS — The Pull Operation
- Top 5 Issues and How to Fix Them
- Configuration Summary Checklist
1. Why gCTS?
Traditional SAP transport management (CTS) is file-based, sequential, and has no native Git integration. gCTS changes that. When you release a Transport Request in your BTP ABAP system, gCTS automatically creates a Git commit and pushes it to your GitHub/GitLab repository. This gives you:
- Full version history of every ABAP object — with line-level diffs in GitHub
- Code review via Pull Requests before deploying to QAS or PRD
- CI/CD pipeline integration (GitHub Actions, Jenkins via Project Piper)
- Instant rollback to any previous commit
- Parallel development using Git branches
— The complete gCTS DevOps lifecycle: developer releases a TR → gCTS pushes to Git → CI server tests → automatic pull to follow-on systems.
Key Concept: gCTS in SAP Public Cloud is Pre-Enabled Unlike On-Premise, you do NOT need to install Git, install Java, configure ICF services, or run an Enablement Wizard. SAP manages all of that internally. Your job starts at the Software Component — everything below that is managed by SAP.
2. Prerequisites
Before you start, make sure the following are in place:
SAP BTP ABAP Environment
SAP_BR_DEVELOPER + SAP_BR_ADMINISTRATOR roles
Eclipse ADT Installed
GitHub Account
Public Repository (or accessible URL)
3. Create Your GitHub Repository and Personal Access Token
We start outside SAP. You need a Git repository and authentication credentials before touching the SAP Fiori Launchpad.
GitHub → Settings → Developer Settings → Personal access tokens → Tokens (classic) → Generate new token
Give your token a recognizable name (e.g., SAP-gCTS-BTP-DEV), set expiration to 90 days, and select exactly these three scopes:
— Required GitHub PAT scopes: repo, delete_repo, and admin:repo_hook. All three must be selected.
Scope Why Required
| repo | Full control of private repositories — read and write access to all content |
| delete_repo | Required internally by gCTS for some repository management operations |
| admin:repo_hook | Required for webhook-based CI/CD pipeline triggering |
Copy the token immediately after creation. GitHub shows it only ONCE. If you navigate away without copying it, you must regenerate a new token. Store it in a password manager — never in a plain text file or email.
GitHub → + (top-right) → New repository
— Create a new private repository with README initialized. The README is mandatory — gCTS cannot clone an empty repository.
Field Value Important Note
| Repository name | z-partner-dev | Use lowercase with hyphens. Convention: z- |
| Visibility | Private | Must be accessible from the internet (not behind a corporate firewall) |
| Initialize with README | Checked | CRITICAL — Creates the first commit. Without this, gCTS clone will fail with an empty repository error. |
After creation, note your repository HTTPS URL — you will need it in Step 5. Example: https://github.com/your-org/z-partner-dev.git
4. Create a Software Component (SAP-side)
This is the most important concept that is unique to SAP Public Cloud gCTS. A Software Component is the container that maps your SAP development to a Git repository. Every ABAP package you create must belong to a Software Component. The mapping is 1:1 — one Software Component = one Git repository.
Public Cloud Only Concept Software Components are required ONLY in SAP Public Cloud. If you are familiar with On-Premise gCTS, there is no equivalent — On-Premise uses Transport Layers + Virtual SID instead. Do not skip this step thinking it is optional.
Fiori Launchpad → Search “Manage Software Components” → Open App
Click the + (Create) button and fill in the following:
Field Example Value Explanation Required?
| Name | ZPARTNER | Use Z or Y namespace. Convention: Z |
| Description | Partner Management Module | Human-readable description for this component. |
| Type | Development | Select “Development” for all custom Z/Y development. |
What happens if you skip this step? You cannot create ABAP packages. When you try to create a package in ADT, you get: “Package must have Software Component assignment”. Without a Software Component, gCTS has no way to track your objects.
Clone the Repository to Your SAP System
Now we connect SAP to GitHub. This is done through the Manage Software Components app (or the gCTS app) by cloning your remote GitHub repository into the SAP system.
gCTS App → Settings ( icon, top-right) → Credentials → Create
Or via Manage Software Components: When you click Clone, SAP will prompt for credentials.
— Where and how to store credentials: gCTS needs your Git provider's API endpoint and token to connect on your behalf.
Field Value Note
| Type | Token | Select Token (not Username/Password) |
| API Endpoint | https://api.github.com/ | CRITICAL: Include the trailing slash! Without it → 401 Unauthorized |
| Token | ghp_xxxxxxxxxxxx | Paste your PAT from Step 1 |
The #1 Setup Error — Missing Trailing Slash
https://api.github.com→ 401 Unauthorizedhttps://api.github.com/→ Works correctlyThis single missing character blocks everything. Check it before any other troubleshooting.
Manage Software Components → Select your component → Clone
Or from the gCTS App: Create a new repository configuration with your GitHub URL, Role = Source, then click Clone.
— The setup sequence: create repository configuration on both DEV and TST/QAS systems, then clone.
After clone, the repository status should show READY (not NEW or ERROR). You can verify in the gCTS App:
— Repository View after successful clone: Status = READY, Role = Development (Source), branch active.
Important: The .gcts.properties.json file After the first clone, gCTS automatically creates a commit in your GitHub repository adding a file called
.gcts.properties.json. This file stores essential gCTS configuration data. Never delete or modify this file — doing so will break future pull operations.
The gCTS App System View now shows your new repository listed with its commit hash, Role (Development / Provided), and status:
— gCTS System View: the home screen showing all repositories registered on this system with their Role, Type, and latest commit.
6. Create ABAP Package and Link to Software Component
Eclipse ADT → Project Explorer → Right-click project → New → ABAP Package
The key field is Software Component — this must match the Software Component you created in Step 3:
Field Value Critical Note
| Name | ZPARTNER | Use same prefix as Software Component for clarity |
| Software Component | ZPARTNER | CRITICAL — Must match Step 3. This is what links the package to gCTS tracking. |
| Transport Layer | (leave empty) | NOT configured in Public Cloud. SAP manages this automatically. |
| Application Component | As appropriate | Optional but recommended for reporting |
When saving, the system will prompt for a Transport Request. Create a new TR for package creation — write a meaningful description as this description becomes the Git commit message.
Wrong Software Component = No Git Commits If you assign the package to the wrong Software Component (e.g., HOME instead of ZPARTNER), ABAP objects created in this package will NOT appear in your Git repository. Transport Requests will release successfully, but no commits will be created. Always verify the Software Component in ADT package properties.
7. Configure Repository Parameters
gCTS App → Select repository → Configuration tab → Create
— The Configuration tab in the gCTS App — add parameters one by one. Each parameter has a Key and Value.
— Important parameters: VCS_AUTOMATIC_PUSH, VCS_AUTOMATIC_PULL, VCS_ERROR_ROLLBACK, and CLIENT_VCS_COMMIT_MESSAGE.
Parameter Value What It Does Rec.
| CLIENT_VCS_TASK_COMMIT | Not required | In SAP BTP ABAP Public Cloud, task-based committing is the default behaviour — a commit is created automatically when a developer releases their Task. No parameter needed. This parameter is only relevant for SAP S/4HANA On-Premise where TR-level commits are the default and task-level must be explicitly enabled. |
| VCS_AUTOMATIC_PUSH | true | Auto-pushes the commit to GitHub immediately after TR release. If false, you must click Push manually in the gCTS App after every TR release. |
| VCS_AUTOMATIC_PULL | false (DEV) / true (QAS/PRD) | Leave unset or set to false on DEV — developers should pull manually to avoid unexpected overwrites in a multi-developer environment. Set to true on QAS and PRD to ensure the system always has the latest merged content before activation. |
| VCS_ERROR_ROLLBACK | true | If a TR release fails at any stage, gCTS automatically rolls back the Git commit. Prevents partial commits from appearing in GitHub. Strongly recommended. |
8. Develop, Release, and Verify Your First Commit
ADT → Right-click package ZPARTNER → New → ABAP Class
Create a simple ABAP class (e.g., ZCL_HELLO_GCTS_### implementing IF_OO_ADT_CLASSRUN). Activate it with Ctrl+F3. Open the Transport Organizer in ADT.
When releasing:
— The push/pull flow: developer releases TR → changed objects are pushed to GitHub. VCS_AUTOMATIC_PUSH and VCS_AUTOMATIC_PULL control the exact behavior.
- Open gCTS App → Select repository → Commits tab
- You should see a new entry at the top with your TR description as the commit message
- Click the commit hash — it should open GitHub showing your ABAP class as
.clas.abapand.clas.xmlfiles - In GitHub, your repository should have a new folder
src/containing your serialized ABAP objects
8.1 Task-Based Committing — Why It Matters
— The problem task-based committing solves: Sandy can't commit her completed work because she's waiting for her colleagues to finish their tasks in the same TR.
Without task-based committing, all developers in the same Transport Request are blocked from committing until the last person is done. With CLIENT_VCS_TASK_COMMIT=X, each developer commits independently when releasing their task. This enables:
- Individual testing without waiting for the full TR
- Finer commit granularity (one commit per developer per feature)
- Reduced interdependencies between team members
— For On-Premise, task-based committing requires a BAdI implementation (SE18 → CTS_REQUEST_CHECK). In Public Cloud, setting CLIENT_VCS_TASK_COMMIT=X in the Configuration tab is sufficient.
— Asynchronous commit (background job) vs Synchronous commit (logon user). For large TRs, asynchronous is recommended. By default, gCTS commits synchronously — the commit runs in the foreground during TR or Task release. For large TRs this can cause a session timeout. To enable asynchronous commits: gCTS App → Configuration tab → add parameter CLIENT_VCS_ASYNCHRONOUS_COMMIT = X. The TR release will complete immediately and the commit runs as a background job. Always check the Activities tab afterwards to confirm the background commit succeeded.
9. Deploy to QAS — The Pull Operation
Deploying to a QAS or Production system in gCTS is done by pulling a commit in the target system. The target system must have the same Software Component configured with Role = Provided.
On your QAS system, configure the same repository but with these differences. Note: The QAS system requires its own GitHub credentials stored independently. Log into the QAS Fiori Launchpad → gCTS App → Settings → Credentials → Create. Use the same PAT and API endpoint (https://api.github.com/) as the DEV system. Credentials are stored per ABAP system and are not shared across systems.
Setting DEV System QAS System
| URL | Same GitHub URL | Same GitHub URL (identical) |
| Role | Source (can push) | Provided (pull only) |
| Branch | dev (or main) | qas (or dev) — aligns with your branch strategy |
| VCS_AUTOMATIC_PULL | true | false (for manual/pipeline-controlled deployments) |
On GitHub: Open a Pull Request from dev → qas. Review the code diff. Approve and merge.
After the merge: Go to your QAS system → gCTS App → Repository → Commits tab. Find the merged commit and click “Update to Latest Commit” or the Pull button.
— The Commits tab in gCTS App: “Update to Latest Commit” deploys HEAD, or click the individual commit's Pull button to deploy a specific version.
Always review the activation log after pulling. gCTS shows an activation result for each object: success, warning, or error. Objects with activation errors are NOT deployed into the system. Fix the error in DEV, create a new commit, and re-pull. Never try to manually fix objects directly in QAS.
10. Top 5 Issues and How to Fix Them
Based on real-world implementations and the openSAP course content, these are the five issues that affect almost every first-time gCTS setup on SAP BTP:
Symptom Root Cause Fix
| 401 Unauthorized during Clone | Missing trailing slash in API Endpoint credentials. Or PAT expired. | Change https://api.github.com to https://api.github.com/ in gCTS Credentials. Regenerate PAT if expired. |
| TR released — no commit appears in GitHub | Package assigned to wrong Software Component. Or VCS_AUTOMATIC_PUSH not set. | Check package properties in ADT — Software Component must match Step 3. Set VCS_AUTOMATIC_PUSH=true in Configuration tab. |
| Clone fails — “Empty repository” | GitHub repository was created without initializing with README — no initial commit exists. | On GitHub: go to repository → Add README file. Or delete and recreate the repository with “Initialize with README” checked. |
| Pull in QAS fails — “Object locked” | An object in the pull set is locked by an open TR in the QAS system (manual change made directly in QAS). | In QAS: check ADT Transport Organizer for locked objects. Release or delete the unauthorized TR. Then retry Pull. |
| Pull in QAS fails — Activation error | Syntax error in the code or missing dependency (referenced class/table not yet deployed). | Fix the code in DEV. Release a new TR. Verify the new commit in gCTS App. Then pull the fixed commit in QAS. Never fix code directly in QAS. |
11. Configuration Summary Checklist
Use this checklist before and after setup to verify everything is in place:
- GitHub repository created with README initialized
- PAT generated with repo, delete_repo, admin:repo_hook scopes
- Software Component created with correct name (cannot be changed later)
- GitHub credentials stored in gCTS App — API Endpoint includes trailing slash
- Repository cloned on DEV — status shows READY
- .gcts.properties.json file visible in GitHub repository
- ABAP package created with correct Software Component assignment
- Parameters set: VCS_AUTOMATIC_PUSH=true, VCS_ERROR_ROLLBACK=true (CLIENT_VCS_TASK_COMMIT not required in Public Cloud)
- First TR released — commit visible in gCTS Commits tab
- Repository configured on QAS with Role = Provided and credentials stored
- First Pull to QAS completed — activation log shows no errors
