11/15/2023
Change and Transport System
Generated on: 2023-11-15 14:30:31 GMT+0000
| 2023 FPS00
PUBLIC
Original content: https://help.sap.com/docs/ABAP_PLATFORM_NEW/4a368c163b08418890a406d413933ba7?locale=enUS&state=PRODUCTION&version=202310.000
Warning
This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product
documentation. The information included in custom documentation may not re ect the arrangement of topics in the SAP Help
Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.
For more information, please visit the https://help.sap.com/docs/disclaimer.
This is custom documentation. For more information, please visit the SAP Help Portal
1
11/15/2023
Git-Enabled Change and Transport System (BC-CTS-GIT)
Git-enabled Change and Transport System (gCTS) enables you to manage your ABAP change and transport management
processes using Git as an external version management system.
Use
You can use gCTS for the following situations:
You're accustomed to Git as a version control system, and now you also want to use it for your ABAP developments and
continuous integration processes.
You're accustomed to ABAP development, and you want to align the processes with your non-ABAP development
processes.
Using gCTS is optional. You can use it to leverage the functions of Git repositories and continuous integration processes. If you
want to test whether gCTS is suitable for your requirements, you can use gCTS for part of your projects, or just for a test
project.
Watch the following video to get an overview of the basic concepts of gCTS:
Open this video in a new window
 Note
For more information about What's New in gCTS, see the ABAP Platform - What's New Viewer and search for Git-Enabled
Change and Transport System.
For the latest information about Git-enabled Change and Transport System and for latest SAP Notes required for your SAP
S/4HANA version, see SAP Note 2821718
Central Note for Git-enabled Change and Transport System (gCTS).
Implementation Considerations
This is custom documentation. For more information, please visit the SAP Help Portal
2
11/15/2023
Git-enabled Change and Transport System consists of different components. You need to con gure the individual
components to make sure that they work together. For more information, see the following topics:
Components of Git-Enabled Change and Transport System
Prerequisites for Git-Enabled Change and Transport System
Con guring Git-Enabled Change and Transport System
Because transporting ABAP objects using gCTS always means connecting a remote repository on a Git server to an
ABAP system, you must make sure that the communication between these components is set up in a secure way. For
more information, see Security for Git-Enabled Change and Transport System in the Application Server ABAP Security
Guide .
Integration
gCTS is integrated in the Change and Transport System. You can only use gCTS in connection with the existing CTS. You
still do your development work in the classic ABAP development environment, for example ABAP Development Tools
(ADT). For an overview of CTS functions, including their meaning and usage in gCTS, refer to CTS Entities Used in gCTS.
In general, you can use gCTS with all Git servers (or Git platforms). gCTS fully supports repositories on GitHub. It's
possible that there are restrictions regarding other Git servers. For known restrictions that aren't described in the
documentation, see the central gCTS SAP Note 2821718
.
gCTS offers project "Piper" steps that let you integrate gCTS with CI/CD pipelines. For more information, see Integration
of gCTS in CI Pipelines.
Constraints
In general, gCTS no longer requires the TMS con guration steps known from the classic CTS. That is, no con guration of the
transport domain, no shared transport directory, no transport layers and transport routes are necessary. For more information
about the invididual entities, see CTS Entities Used in gCTS.
However, if you want to transport change requests created for SAP Note implementations or modi cation adjustment
transports after Support Package imports, you require a classic transport landscape. These change requests can't be pushed to
Git repositories and are not supported by gCTS. If you want to transport these requests to follow-on systems, you must
continue to use the classic CTS setup.
Related Information
Git-Enabled CTS on SAP Support Portal
Guided Answer: Troubleshooting Git-Enabled Change and Transport System
Blogs about gCTS in SAP Community
Git on https://git-scm.com
Basics of Git-Enabled Change and Transport System (gCTS)
The following sections describe the concept of gCTS, its features and its entities. They also explain the meaning that important
entities of CTS and Git have in the context of gCTS.
Git-Enabled Change and Transport System - Concept
Git-enabled Change and Transport System (gCTS) lets you store all versions of ABAP development and Customizing
objects in Git repositories.
Features of Git-Enabled Change and Transport System
gCTS features in a nutshell.
CTS Entities Used in gCTS
This is custom documentation. For more information, please visit the SAP Help Portal
3
11/15/2023
As a rule, the entities known from the classic Change and Transport System (CTS) or the enhanced CTS (CTS+) are also
used in Git-Enabled Change and Transport System (gCTS). However, either the relevance of some entities has changed,
or some entities must be used in a gCTS-speci c way.
gCTS Entities and Git Entities Explained
The following sections contain background information about speci c gCTS-entities as well as the usage of Git-speci c
entities in gCTS.
Git-Enabled Change and Transport System - Concept
Git-enabled Change and Transport System (gCTS) lets you store all versions of ABAP development and Customizing objects in
Git repositories.
gCTS makes use of Git features, such as working on local copies of a central remote Git repository. Software development is
done in the usual editors, for example in ABAP Development Tools (ADT). Changes to objects are still recorded in transport
requests. Current states of objects can be transferred to remote Git repositories - this process is called pushing objects to the
remote repository - either by releasing a transport request, or a task while you’re working.
ABAP objects are copied into a local repository on the ABAP system. In this process, they’re transformed from database table
content to le and folder structures on the operating system level. These are stored in the local le system of the application
server, the local repository, and are accessible from any command-line versioning tool, such as Git. This way, the ABAP le
objects can be pushed to a central remote Git repository. This allows you to distribute software between systems using Git. You
can retrieve the software from the central remote Git repository to use it on another ABAP system. This process is called
pulling objects from the remote repository.
As a prerequisite, you need to de ne which ABAP packages in an ABAP system are managed by which repository in gCTS, and
then assign a gCTS-speci c transport layer to the packages.
The following is an overview of the process:
ABAP objects are created or changed in development systems. In development systems, you can con gure repositories with the
Development role. The ABAP objects can be pushed to a central remote Git repository. For systems that you want to distribute
these developments to, you can con gure repositories with the Provided role. In these systems, you can pull the required ABAP
development objects. These systems can be another development system, as well as a test, or a production system. This way,
you don’t need to con gure transport routes between ABAP systems and you don’t need a shared transport directory.
Features of Git-Enabled Change and Transport System
gCTS features in a nutshell.
Capability to store your ABAP developments in Git repositories
Central version management, Git server (GitHub, for example), for cloud storage
This is custom documentation. For more information, please visit the SAP Help Portal
4
11/15/2023
Multi-repository support
You can have multiple repositories on one ABAP system. For example, you could have one repository for each project and
one for Customizing data.
SAP Fiori app for gCTS (gCTS app) providing access to common Git functions, such as cloning the remote Git repository
to the ABAP system, committing ABAP objects, pushing the commits to the remote repository, and pulling changed
objects to target systems.
Development process remains in the ABAP development system (ADT, for example).
Support and versioning for nearly all ABAP development and Customizing objects
For restrictions, see SAP Note 2888887
: gCTS: restrictions in supported object types
Provisioning of objects in the remote repository for every ABAP system that has a connection to the Git server.
No longer required: A shared transport directory and import queues to ensure the correct import sequence, and prevent
unwanted software downgrades, as required in the classic CTS.
Leverage of the deployment and logging capabilities of the transport tools by internally working with transport data les,
as known from the classic CTS.
Continuous integration capability
Performance improvements through the aggregation of changes
CTS Entities Used in gCTS
As a rule, the entities known from the classic Change and Transport System (CTS) or the enhanced CTS (CTS+) are also used in
Git-Enabled Change and Transport System (gCTS). However, either the relevance of some entities has changed, or some
entities must be used in a gCTS-speci c way.
Basics of CTS with Regards to gCTS
The following table uses the topics of the Basics of the Change and Transport System documentation as a basis to explain basic
similarities and differences between CTS and gCTS.
Topic in CTS
Important Aspects in gCTS
Documentation
Change Management in
You continue to use the existing Customizing and ABAP development tools to adapt SAP software to your
the SAP System
business processes. You use change requests and tasks to record your changes. Your changes to ABAP
Landscape
objects are still stored in the ABAP database.
In addition, in gCTS, ABAP objects are converted to les and are stored in Git repositories on Git servers.
Clients and Their Roles
You can use gCTS when you work with client-speci c Customizing data. To do this, we recommend that you
use a separate Git repository, and the gCTS registry. For more information, see About Using gCTS for
Customizing Data.
This is custom documentation. For more information, please visit the SAP Help Portal
5
11/15/2023
Topic in CTS
Important Aspects in gCTS
Documentation
System Landscape
You still have different systems with different roles, such as development, test, and production systems, as
with the classic CTS.
However, the con guration of the system landscape is done differently when you use gCTS. The
representations of the Git repositories become part of the landscape. This is re ected by separate transport
layers and transport routes to gCTS-speci c virtual non-ABAP systems, the so-called vSIDs. For more
information, see About the vSID.
There's also the option of using continuous integration pipelines. For example, as shown in the Git-Based
Continuous Integration use case.
Transport Organizer -
You still use the Transport Organizer for organizing your development projects. Only one active version of an
Concept
object exists in the system. Objects are locked, and changes are recorded in change requests and tasks.
To further integrate gCTS with Transport Organizer processes, for example to push changed objects of a
released task to a Git repository, a Business Add-In (BAdI) is available for implementation. For more
information, see Integrate the gCTS Registry with the Transport Organizer.
Transport Management
If you want to use only gCTS, you no longer need to con gure a classic system landscape with a transport
System - Concept
domain controller, transport routes between the systems, and a transport directory. By default, after
installation, a system is con gured to be a transport domain controller. We recommend that you leave this
setting unchanged. This simpli es the gCTS con guration. No further con guration is then required in TMS.
In gCTS, all ABAP systems are still visible in the Transport Management System (TMS). Therefore, you must
run the initial activation of TMS in every system, even if you plan to use gCTS only. For more information, see
Con guring the Transport Domain Controller.
 Note
If you want to transport requests created for SAP Note corrections, or modi cation adjustment transports
between systems, you must continue to con gure the classic CTS. For more information, see the
constraints mentioned in SAP Note 2821718
.
If your system is already part of a landscape where a domain controller exists, you can continue to work with
this setup. No changes are required.
Imports in target systems are performed by pulling commits. The import process remains the same.
However, it's no longer started in transaction STMS. For more information, see Import Queue.
Transport Layers and
Transport Layer: gCTS uses transport layers as a vehicle to group development projects. gCTS still
Transport Routes
uses transport layers when developing ABAP objects with gCTS, and for target systems of requests
used for Customizing objects, if the gCTS registry is not used. If the gCTS registry is used, the
registry determines the target repository of pushed objects. In this case, it is possible to use one
transport layer for all repositories, and requests used for Customizing objects no longer need a target
system.
By assigning a transport layer to a package, you can de ne whether the package uses the classic CTS
or gCTS. The transport layer in gCTS is composed of a Z followed by the vSID of the repository. For
more information, see De ne ABAP Packages as Managed by Git-Enabled Change and Transport
System and About the vSID.
Transport Route: In gCTS, transport routes are no longer needed to connect different systems of your
landscape.
They are used as a vehicle to connect the ABAP system and the non-ABAP system used as the vSID
of the Git repository, if the gCTS registry is not used. The transport layer is assigned to this route, and
the correct transport target, that is, the correct Git repository, can be determined. If the gCTS registry
is used, the correct target repository is looked up in the registry.
If transport routes already exist in your transport landscape, and you want to use gCTS only for
managing some of your developments, you can continue to use the existing transport routes.
This is custom documentation. For more information, please visit the SAP Help Portal
6
11/15/2023
Topic in CTS
Important Aspects in gCTS
Documentation
Assignment of
Packages used with gCTS must have a transport layer assigned that is different from the one used by the
Development Projects to
consolidation route that points to the follow-on system in your landscape. For more information, see De ne
Transport Layers
ABAP Packages as Managed by Git-Enabled Change and Transport System.
Additional CTS Terms and Their Meaning in gCTS
CTS Term
Meaning in gCTS
This is custom documentation. For more information, please visit the SAP Help Portal
7
11/15/2023
CTS Term
Meaning in gCTS
Change Requests
In the classic CTS, when developers change or create ABAP objects, the changed objects are recorded in
change requests. Tasks are created in change requests for developers working on objects of the same
package. Objects are locked until the task is released. Only developers who are part of the request can work
on the locked objects. After all tasks are released, the change request can be released. In the classic CTS, a
released change request is put in the import queue of the follow-on system in the landscape. It can be
automatically imported into this system (for example, by using a job) or be done manually. The import ends
with a return code that states whether the import was successful. For more information, see Change Requests.
In gCTS, change requests are also leveraged, but with a different focus.
On source systems: When gCTS is used for development, change requests still exist. They're used for
organizing development. They're released after all the tasks are released. Releasing a change request
creates a commit in the local Git repository in the branch that is currently active. The objects of the
change request are converted into les, and the commit is pushed to the remote Git repository. For
more information, see gCTS: Process Overview.
Optionally, you can implement a Business Add-In (BAdI) that enables pushing the changed objects of
a released task to a Git repository. For more information, see Integrate the gCTS Registry with the
Transport Organizer.
On target systems: In gCTS, change requests are no longer automatically forwarded to the import
queue of follow-on systems. Git is now the leading versioning tool. You can choose from existing Git
commits which one you want to pull into a target system. When a commit is pulled, a new change
request is created that contains the objects that are part of the commit to be imported and that are
different from the version of the objects of the current commit.
The request has the following characteristics:
The short description contains the repository name and information about the commits that
were involved in the request.
 Example
test-repo1: git commit from 02f269a to 025055a
The request number is a generated hash value. For more information, see Change Request
Numbers.
It has the following additional request attributes:
COMMIT: Commit that is pulled.
COMMIT_AUTHOR: Author of the commit that is pulled.
COMMIT_DATE: Date and time when the commit was created.
PREVIOUS_COMMIT: Current commit in the target system.
REPOSITORY: Name of the repository where the commit is pulled.
The import is started automatically by the pull action. You don't start it in the Transport Management
System (transaction STMS). To check details about the import, such as request attributes, and import
logs, you can use the import history.
 Note
It is important to understand that even though change requests are used to organize development and
create commits, they don't have the same role as in the classic CTS. Change requests are not persisted in
repositories. Each new commit creates a version of the software. When a commit is pulled on a target
system, the new generated change request contains the object differences between the commit to be
pulled and the current commit. The generated change request cannot be attributed to a speci c change
request created in the development system. For more information, see About Commits in gCTS.
This is custom documentation. For more information, please visit the SAP Help Portal
8
11/15/2023
CTS Term
Meaning in gCTS
Tasks
The idea of tasks hasn't changed in gCTS. Developers record their changed objects in tasks belonging to
change requests. Objects are locked for other developers while they're part of an open task. For more
information, see Changing Objects.
When the Business Add-In (BAdI) is implemented as described in Integrate the gCTS Registry with the
Transport Organizer released tasks can trigger pushes to Git repositories.
Change Request
On source systems: The number of the change requests still follows the classic format: <System ID
Numbers
(SID) of the development system>K<number>
On target systems: A new change request is generated when you pull a commit.
The number of the change request is a generated hash value, taken from the commit ID of the related
Git repository, which leads to a number with the maximum available length <vSID>K<16-
character commit hash>, for example GITK41TBD3BG5QT1EKAO.
For more information, see About the vSID.
Locked Objects
In development systems, objects are locked for development when they are assigned to a change request. For
more information, see Transport Organizer - Concept.
This is also true when using gCTS.
In gCTS, locked objects are displayed on a dialog box when objects that are currently locked in an open
request, are imported in a system, for example after resolving a con ict, by pulling a commit, or by switching
the branch of a repository. If you proceed, the object locks for these objects are ignored until the import is
complete, and the object version is overwritten by the object version that is part of the commit. If you've
made local changes to an object, for example a local repair, the local changes are lost.
Import Queue
In the classic CTS, an import queue serves the following purposes:
Before an import, it provides a list of released change requests ready for import in a system
During an import, the transport control program tp logs the processed import steps so that a broken
import can be resumed, if issues occur.
In gCTS, such a queue is no longer necessary. When a commit is pulled, a new request is generated that
contains the object differences between the commit to be pulled and the current commit. For more
information, see Change Requests. But, as in the classic CTS, the import queue serves as a place where tp
logs the performed import steps.
Import History
The import history allows you to display all requests imported into a system. It shows all transport steps of a
request with their return codes. Also, in gCTS, you can use the import history to check processed import
steps of the generated change requests. For more information, see Change Requests and Using the Import
History.
Return codes
In general, an import in a target system generates the same return codes as in the classic CTS. On the
Activities tab, an icon displays an aggregated status of the activity. Import logs can be used to analyze errors.
By default, as of SAP S/4HANA 2022 gCTS considers a return code of 8 as an error. You can in uence this
display using a repository con guration parameter. For more information, see VCS_IMPORT_ERROR_LEVEL.
Non-ABAP System
In gCTS, the idea of a virtual non-ABAP system known from the enhanced CTS (CTS+) is reused in the socalled vSID, a non-ABAP system of type version control system. A vSID is required when you create a
repository on an ABAP system. It serves different purposes, for example assigning packages to repositories,
if the gCTS registry isn't used. For more information, see About the vSID.
After Import Methods
XPRAs aren't supported by gCTS. The reason is that change requests are created based on the differences
(XPRAs)
between the commit that is currently active in your ABAP runtime and the commit that you chose to pull. All
objects with differences are included in a single change request. If any code parts require an XPRA to be run
after the import, it can't be done in gCTS. This is because, instead of importing all the change requests (and
running all after-import methods), only one change request is created and imported. It's impossible to
manually alter this change request to include the XPRA.
This is custom documentation. For more information, please visit the SAP Help Portal
9
11/15/2023
CTS Term
Meaning in gCTS
Transport Directory
In general, gCTS no longer needs a shared transport directory as required in the classic CTS.
 Note
If you want to transport requests created for SAP Note corrections, or modi cation adjustment transports
between systems, you must continue to con gure the classic CTS, including the transport directory. For
more information, see the previous section: TMS - Concept.
gCTS Entities and Git Entities Explained
The following sections contain background information about speci c gCTS-entities as well as the usage of Git-speci c entities
in gCTS.
gCTS Registry
Use the gCTS registry to assign ABAP objects contained in change requests to a speci c Git repository.
About the vSID
When you create a Git repository on your ABAP system, you must enter a so-called vSID.
About Commits in gCTS
A commit in Git represents a snapshot of a Git repository at a speci c point in time.
About Versions of Repositories in gCTS
You can use branches and tags to de ne versions of repositories in gCTS.
References to Git Documentation
The Git-Enabled Change and Transport System (gCTS) leverages Git functions with the aim of managing ABAP
development using Git repositories. The following topic provides a collection of links to documentation of Git concepts
and functions.
gCTS Registry
Use the gCTS registry to assign ABAP objects contained in change requests to a speci c Git repository.
Use
If you use gCTS without the registry, gCTS-speci c transport layers and assignments of ABAP packages to these transport
layers are used to organize the relationship between a Git repository and the objects in a transport request. The gCTS registry
aims at a closer integration between ABAP objects and Git repositories. The gCTS registry can reduce manual efforts in
situations such as the following:
For Customizing Objects
Customizing objects don't have any package assignment. Every time a transport request for Customizing objects is
created, the correct transport target of the request, which is used to determine the correct Git repository, must be
manually assigned.
 Recommendation
We recommend that you use the gCTS registry for Customizing objects.
For Distributed Development
This is custom documentation. For more information, please visit the SAP Help Portal
10
11/15/2023
In a distributed development environment, where developers work in multiple ABAP development systems, all
developers must know about the structure of the repositories that exist for their projects. To do this, they must manually
ensure that all objects that belong to the same package, but have been developed by different developers in different
systems, are assigned to the same Git repository.
If you use the gCTS registry, only one transport layer is required. You use the same virtual non-ABAP system (vSID) for all
repositories that use the registry. You can register all Customizing objects that you create in a system in the same repository.
Source code-based objects for which the gCTS registry is used can be distributed among different project-based repositories.
All systems where you want to use the gCTS registry have to be connected to a gCTS registry server with high availability, for
example the production system. Registration is possible on any ABAP system that is connected to the registry server. All
systems where objects are changed require a connection to the registry server. These are usually development systems. You
can register ABAP objects in the gCTS registry, even before the objects are created.
 Note
For more information about the gCTS registry, see SAP Note 3046346
: gCTS Registry: Central Note .
Prerequisites
Using the gCTS registry that's integrated into your ABAP development or Customizing processes is supported only if you
implement a Business Add-In (BAdI) that is run when you release a transport request or task. Make sure you implement
the BAdI in all development systems before you start using the registry.
For more information, see Integrate the gCTS Registry with the Transport Organizer.
General Process
Working with the gCTS registry includes the following work ow:
Step
Description
More Information
1
Make one of your ABAP systems the gCTS registry server.
Con gure the gCTS Registry
2
Connect your development systems to the gCTS registry server.
3
Register Git repositories in the gCTS registry.
Register Git Repositories in the gCTS Registry
4
Optional: Register repository branches in the gCTS registry.
Display and Change Repository Details in the gCTS
Registry
5
Register all objects that belong to registered repositories in the gCTS
Register ABAP Objects in the gCTS Registry
registry.
6
7
Integrate the gCTS registry with the Transport Organizer, if you haven't
Integrate the gCTS Registry with the Transport
previously done this.
Organizer
Perform your Customizing and development tasks as usual.
About Using gCTS for Customizing Data
When you use the gCTS registry for Customizing data, make sure you
use the vSID, which you've de ned for the registry, as the target system
for transport requests.
Related Information
Con gure the gCTS Registry
Use the Registry Tab of a Repository
This is custom documentation. For more information, please visit the SAP Help Portal
11
11/15/2023
About the vSID
When you create a Git repository on your ABAP system, you must enter a so-called vSID.
This is a three-character system ID of a virtual non-ABAP system, which is unique in your transport landscape. The non-ABAP
system is created automatically if the ABAP system where you create the Git repository is a domain controller. If the ABAP
system isn't a domain controller, the non-ABAP system has to be created manually. The non-ABAP system is of a special type
VCS (version control system). You can display it in the Transport Management System of your ABAP system using
Overview
Systems . In development systems, transport routes are created to the non-ABAP systems, which are assigned to gCTSspeci c transport layers.
 Example
Example of a vSID: DEV
Purpose of the vSID
The vSID is required for different purposes:
On source systems where the gCTS registry is not used: The vSID is used as the import target.
If the role of a repository is Development (used for source systems), the non-ABAP system is used as the import target
of change requests, which are created in the ABAP system and which use a gCTS-speci c transport layer.
By default, all change requests that you release in your ABAP development system, which use a gCTS-speci c transport
layer, are put in the import queue of the non-ABAP system using the transport layer that was created for it. From there,
they're automatically pushed to your remote Git repository by default.
This way, developments managed by gCTS can be separated from developments managed by the classic CTS.
 Note
If you already have an existing transport landscape that uses the classic CTS, you can continue to use the existing
transport landscape for the developments that don't use gCTS.
On source systems where the gCTS registry is used: You still need a vSID to create a repository on an ABAP system. But
the registry determines into which repository an object is pushed. You can use the same vSID for all repositories that use
the registry. For more information, see gCTS Registry.
The names of gCTS-speci c transport layers are derived from vSIDs.
The name of the non-ABAP system serves as the basis for the name of the transport layer used for gCTS-managed
developments in the ABAP system. The name of the transport layer follows this naming convention Z+<vSID>.
 Example
Example of a transport layer: ZDEV
On target systems, the vSID is the source system for generated change requests.
If the role of the repository is Provided (used for target systems), the non-ABAP system serves as the virtual source
system of change requests that are created internally on the ABAP target system, with each pull from the remote Git
repository to the ABAP system.
The number of generated change requests are derived from the vSID.
The generated change requests created for the import in an ABAP target system are derived from the non-ABAP
system. For more information, see Change Request Numbers.
This is custom documentation. For more information, please visit the SAP Help Portal
12
11/15/2023
When you pull a commit, a change request is created. You can display the change request on the Activities tab. Change
requests are used as a container to import and activate ABAP objects in the ABAP target system.
How the vSID is Created
The vSID is created in the following ways:
If the ABAP development system is a domain controller, the non-ABAP system is automatically created when you create
a Git repository on your ABAP system.
This triggers the following actions in Transport Management System:
Automatic creation of a non-ABAP system with the following details:
Parameter
Value
System
<vSID> as entered
Description
gCTS generated
Transport tool parameter:
<SID of domain controller>
COMMUNICATION_SYSTEM
Transport tool parameter: NON_ABAP_SYSTEM
VCS
Transport tool parameter: CTC (client transport
0
control)
 Note
This parameter is generated only if it's needed.
Automatic creation of a gCTS-speci c transport route of type Consolidation and a transport layer with the
following details:
Field
Description
Integration system
<SID of current ABAP system>
Transport layer
Z<SID of non-ABAP system>
Consolidation system
<vSID>
Distribution of the con guration in the transport domain.
For more information, see Create Git Repositories on an ABAP System.
If the ABAP development system isn't a domain controller, you have different options as described under Prepare ABAP
Systems for Repositories.
Recommendations
If you push content to the same repository from different development systems, you must use the same vSID in all development
systems. Otherwise, you can't work on objects that were created in another development system.
If you create a repository on a target system to pull content from the corresponding development system, it isn't mandatory
that you use the same vSID. Nevertheless, using the same vSID can be useful for traceability reasons, for example to
understand where certain changes came from.
This is custom documentation. For more information, please visit the SAP Help Portal
13
11/15/2023
Related Information
CTS Entities Used in gCTS
About Commits in gCTS
A commit in Git represents a snapshot of a Git repository at a speci c point in time.
Commits in Git
A commit is identi ed by a commit hash.
Each commit typically includes the following information:
Author: The user who triggered the commit.
Timestamp: The date and time when the commit was created.
Commit message: A description of the changes made in the commit.
When you create a commit, Git compares the changes you made to the previous commit of the repository and creates a new
commit that represents those changes. The commit is then added to the repository's history, and the repository is updated to
re ect the new state. Commits are essential for collaboration and version control in Git. They provide a way to track and
manage changes, revert to previous states, and collaborate with others by sharing and merging commits.
For more information, see Recording changes to the repository including committing changes to the repository.
Commits in gCTS
A Git repository typically contains a complete software component , that is, a set of software objects that are to be developed
and delivered together. When you start working with gCTS, you can either start with a new development project (for example a
new ABAP package), or you can transfer an existing state of a software component (for example an existing package) to a Git
repository. For more information, see How to Onboard Existing Developments to gCTS.
gCTS works with Git commits using change requests for export and import. Commits are created in the local repository in the
branch of the repository that is currently active in the system. By default, a commit is created when a change request is
released in a source (development) system. The ABAP objects contained in the change request are converted into les which
are committed to the local repository and are then pushed to the remote repository. With each new commit, a new version of
the software component is created. They aren't delta transports even though change requests are used to record object
changes.
 Note
When an ABAP object is committed to a Git repository for the rst time, the complete object must be pushed. Partial objects
(LIMU) are only allowed when the complete object was committed at least once. If commits with partial objects are pulled to
target systems where no corresponding complete object exists, the import fails.
When a commit is pulled in a target system, gCTS compares the objects of the commit to be pulled with those of the current
commit. All objects that differ between the commits are aggregated into a new generated change request that contains all
changes between the two commits. This means, not only the objects changed in this commit, but also all objects that are
different between the two commits are imported. The generated change request can be compared to a delta merge transport.
It is imported with the default logic of the Transport Management System. The number of the request is different from the
number of the request that was used when the objects were exported from the development system. For more information, see
the Change Requests section in the CTS Entities Used in gCTS topic.
This is custom documentation. For more information, please visit the SAP Help Portal
14
11/15/2023
 Caution
Using the manual deploy function on the Objects tab with the Deploy Scope = Current Commit imports the version of the
software component of the repository of the current commit. This means, all objects are important instead of only a delta.
For more information, see Manually Deploy Objects.
Creating Commits
Commits are created in the following situations:
When you release a change request with ABAP objects.
If the gCTS Business Add-In (BAdI) is implemented: When you release a task.
When you manually commit les, for example after you've resolved a con ict.
For more information, see Manually Commit Files.
When you manually push objects.
For more information, see Manually Push Objects.
When merging branches.
For more information, see Merge Branches of a Repository.
Scenarios Where No Commit is Created
When gCTS doesn't detect any changes in the objects to be committed compared to the current state of the objects in the
repository, no new commit is created. However, a new COMMIT process is displayed on the Log tab with a green (success) state
. In the log details, a tp log message can be found stating that no changed objects were found and that there's nothing to do.
This behavior can occur in the following situations:
When you release a change request that doesn't contain any changed objects, for example because all changed objects
were already committed by released tasks.
When you manually push an empty change request or task.
 Note
Nevertheless, it is possible that a commit is created when you release a task or a change request that was previously pushed
manually. This is because releasing a task or a request can result in property changes of objects that gCTS recognizes as a
change.
 Note
When you pull a commit that doesn't contain any changed objects, neither a change request is generated because no objects
need to be imported, nor an activity is displayed on the Activities tab.
About Versions of Repositories in gCTS
You can use branches and tags to de ne versions of repositories in gCTS.
In gCTS, the default version of a repository is set as 1.0.0. The version can be seen in the .gcts.properties.json le. When
a new branch is created, a separate version of the gCTS properties le is created in the new branch.
This is custom documentation. For more information, please visit the SAP Help Portal
15
11/15/2023
When a new tag is created for a current commit using the semantic versioning format, gCTS updates the version information in
the gCTS properties le of the active branch.
When creating a dependency to another repository, you can specify a version of the repository as the dependency.
Related Information
The gCTS Properties File
Create Branches in a Repository
Create Tags
Set Dependencies of a Repository
References to Git Documentation
The Git-Enabled Change and Transport System (gCTS) leverages Git functions with the aim of managing ABAP development
using Git repositories. The following topic provides a collection of links to documentation of Git concepts and functions.
Links to Git
Topic in gCTS
Required Git
Link to Git Information
GitHub-speci c information
https://git-scm.com/
https://docs.github.com/en/get-started
Function
Git-Enabled Change and
General
Transport System -
information
Concept
about Git
Prerequisites for Git-
Getting a Git
https://git-scm.com/book/en/v2/Git-
Enabled Change and
repository
Basics-Getting-a-Git-Repository
Transport System
https://docs.github.com/en/getstarted/quickstart/create-a-repo
https://docs.github.com/en/accountand-pro le/setting-up-andmanaging-your-github-useraccount/managing-access-to-yourpersonal-repositories/invitingcollaborators-to-a-personalrepository
Creating a personal access token
For gCTS, you need the repo scopes
including delete repositories, and the
user scopes.
About Commits in gCTS
Recording
https://git-scm.com/book/en/v2/Git-
changes to the
Basics-Recording-Changes-to-the-
repository
Repository
including
committing
changes to the
repository
Reset Local Repository
git-reset
https://git-scm.com/docs/git-reset
Use the Branches Tab of a
Git branching
https://git-scm.com/book/en/v2/Git-
Repository
Branching-Branches-in-a-Nutshell
This is custom documentation. For more information, please visit the SAP Help Portal
16
11/15/2023
Topic in gCTS
Required Git
Link to Git Information
GitHub-speci c information
Function
Use the Con ict
Git merging
https://git-
Resolution Editor
scm.com/book/en/v2/GitBranching-Basic-Branching-and-
Merge Branches
Merging#_basic_merge_con icts
of a Repository
Merge strategies:
https://gitscm.com/docs/merge-strategies
Merge options: https://gitscm.com/docs/merge-options
Use the Tags Tab of a
Git tagging
Repository
Create Tags
https://git-scm.com/book/en/v2/GitBasics-Tagging
.
git-check-ref-
https://git-scm.com/docs/git-check-ref-
format
format
Use Cases of Git-Enabled Change and Transport System
Git-enabled Change and Transport System supports the use cases Git-Based Software Distribution and Git-Based Continuous
Integration.
Git-Based Software Distribution
You can use Git as the technical basis of software distribution.
Git-Based Continuous Integration
gCTS allows you to set up continuous integration processes for ABAP development.
Git-Based Software Distribution
You can use Git as the technical basis of software distribution.
You can select any software version and deploy it to an ABAP system by selecting a commit in the corresponding Git repository.
The following animated graphic shows how the process works when you transfer ABAP development objects from one system to
another using Git-based distribution:
This is custom documentation. For more information, please visit the SAP Help Portal
17
11/15/2023
Any type of ABAP development and Customizing object can be stored in a Git repository. Whenever objects are changed in a
development system, the classic CTS will record them in transport requests and tasks. gCTS uses these transport requests and
tasks to transfer and commit the contained objects to a local repository. From there, the commits are pushed to a central Git
repository ‒ the remote repository.
The objects in the remote repository can then be transferred into the local repository of any target system, and imported in this
system. Internally, the well-known transport tools provide fast import, automatic object activation, and the running of afterimport methods.
gCTS enables you to perform a rollback to a previous commit directly after importing a commit.
 Caution
Use the option to roll back imports only in test and quality assurance systems where you can immediately revert errors.
Don’t use it in production systems.
Git-Based Continuous Integration
gCTS allows you to set up continuous integration processes for ABAP development.
In many development environments, continuous integration (CI) processes are used. They help manage code changes made by
multiple developers and bring the changes together in one integration system as often and early as possible. Developers can
begin by working independently on the features they’re responsible for. Whenever a feature is ready for an integration test, the
developers can promote their developments to an environment where the features and xes implemented by different
developers can be integrated and tested together.
gCTS safeguards the advantages of a central development environment and, at the same time, makes sure that ABAP
development processes can be managed in the same way as in other development environments. This includes the option to set
This is custom documentation. For more information, please visit the SAP Help Portal
18
11/15/2023
up new development or testing systems with any selectable state of the coding. This state can be taken from a repository that
keeps track of different releases and feature development.
In the classic Change and Transport System, transport requests are used to integrate changes into other systems. Transport
administrators with sufficient permissions do imports in the target systems. Imports are usually not done by developers. Over
time, this has led to a task separation between developers who release transport requests and transport administrators who
maintain import queues ( lled with transport requests) and trigger the imports. This transport process works but has its limits.
It can help in highly regulated environments. But in some cases, it isn’t exible enough and isn’t suitable for state-of-the-art
development processes and tools that are used in CI or DevOps. Especially if you work in a heterogeneous development
environment, which includes non-ABAP applications, the processes for the different platforms are different and can hardly be
harmonized.
gCTS prepares ABAP for CI processes and provides options to set up similar development processes for ABAP and non-ABAP
platforms.
You can set up CI pipelines that update your target systems automatically. CI processes involve using a pipeline that de nes a
sequence of steps to be performed and conditions that control the pipeline.
gCTS is integrated into Project "Piper". It provides gCTS steps that you can use in your pipeline. For more information, see
Integration of gCTS in CI Pipelines.
The following animated graphic illustrates what the process could look like:
In this example, there's a remote project repository on a Git server with three branches (dev, qa , prod) for three different
codelines for development, quality assurance, and production. There's a common three-system landscape with a Dev system, a
QA system, and a Prod system.
Each system is subscribed to its related branch (dev, qa , prod). This means that the repository was created and cloned to all
systems. The difference is this:
In the Dev system, the dev branch is the active branch.
This is custom documentation. For more information, please visit the SAP Help Portal
19
11/15/2023
In the QA system, the qa branch is active.
In the Prod system, the prod branch is active.
The work ow is as follows:
1. When a developer commits a change to the local repository in the Dev system, the commit is pushed to the dev branch
of the remote repository.
2. A CI server observes the remote repository for new changes (in the form of new pull requests). The pipeline in the CI
server is con gured in a way that it's triggered when a new pull request arrives for the qa branch.
When a developer merges the dev branch into the qa branch, and a pull request is created, the CI server is triggered.
3. The CI server automatically pulls the changes from the qa branch to the QA system, and imports them there.
4. In the QA system, manual and automatic tests can be performed. Automatic tests could also be triggered by the pipeline
in the CI server (not shown in the animated graphic).
5. If tests in the QA system are successful, a developer or an admin user can manually merge the qa branch into the prod
branch.
6. The CI server is triggered, and it automatically pulls the changes from the prod branch to the Prod system, and imports
them there.
More Information
Continuous Integration and Delivery by SAP
gCTS: Process Overview
The following image map gives an overview of the steps involved when using gCTS to manage your development projects.
Please note that image maps are not interactive in PDF output.
Components of Git-Enabled Change and Transport System
The following components are required for Git-enabled Change and Transport System (gCTS).
This is custom documentation. For more information, please visit the SAP Help Portal
20
11/15/2023
Please note that image maps are not interactive in PDF output.
Prerequisites for Git-Enabled Change and Transport System
To work with Git-enabled CTS (gCTS), the following prerequisites must be ful lled.
 Note
The following tasks must be performed by system adminstration.
Prerequisite SAP Notes
Before you start working with gCTS, refer to SAP Note 2821718
for known issues in your SAP S/4HANA version. Implement
all SAP Notes correcting known issues in your SAP S/4HANA version.
Prerequisites: SAP Fiori App for Git-Enabled Change and Transport System (gCTS
App)
The gCTS app is the starting point for your gCTS con guration activities, as well as for using gCTS. To use the app, you must rst
implement it.
For more information, see App Implementation: Git-Enabled Change and Transport System.
Prerequisites: ABAP System
ABAP users who work with gCTS require authorizations depending on the tasks they need to perform and the
repositories that they need to access in the ABAP system. For more information, see Authorization Concept in gCTS.
gCTS requires the scheduled job SCTS_ABAP_VCS_IMPORT_OBSERVER in transaction SM37 to run the program
SCTS_ABAP_VCS_IMPORT_OBSERVER that observes the repositories on the ABAP system. If the ABAP system is a
domain controller, the program con gures mandatory settings for the Transport Management System. If the ABAP
system isn’t a domain controller, later when you create repositories on the ABAP system, you must prepare your ABAP
systems for the repositories. For more information, see Prepare ABAP Systems for Repositories.
The scheduled job is triggered whenever a change request is added to the import queue of the non-ABAP system (vSID)
that's assigned to the repository. It imports and commits the objects (new, changed, and deleted objects) of the
transports into the corresponding local repository.
This is custom documentation. For more information, please visit the SAP Help Portal
21
11/15/2023
By default, the job is scheduled for the user who enables gCTS. We recommend that you schedule the job with a technical
user. To do this, create a technical user in the ABAP system, and assign the authorizations of the SAP_BC_GCTS_ADMIN
role to this user. Then enable gCTS using the technical user.
For more information, see Enable Git-Enabled Change and Transport System in an ABAP System.
Prerequisites for the gCTS registry: For Customizing objects, we recommend that you use the gCTS registry. The gCTS
registry that's integrated in your Customizing process is supported only when you implement a Business Add-In (BAdI)
that's run when you release a change request or task. Make sure you implement the BAdI in all development systems
before you start using the registry.
For more information, see gCTS Registry and Integrate the gCTS Registry with the Transport Organizer.
Prerequisites: Operating System
The Git client abap2vcs.jar is written in Java. In a standard ABAP system installation, it’s part of the standard SAP
Kernel. To run the Git client, a Java runtime environment is required, which you must install manually. An Open JDK
version of at least 10 is required.
Optionally, you can use SAPMachine as Java runtime. For more information, see https://sap.github.io/SapMachine/
.
The current version (Long Term Support) can be used with gCTS.
If you use multiple application server instances, the Java runtime must be on a shared directory to avoid inconsistencies
and data loss. To share directories between application server instances, you can use Network File System (NFS), or
Server Message Block (SMB). A separate share is required for every individual ABAP system in your landscape.
 Example
Example of a shared Java runtime directory on Unix: /<my-shared-directory>/<SAPSID>/<my-java-
directory>/bin/java.
 Note
Remember the path to the Java executable of the Java runtime. You’ll need to enter it when you con gure gCTS. For
more information, see Enable Git-Enabled Change and Transport System in an ABAP System.
gCTS requires a working directory called gcts on the operating system. You must create this working directory, for
example in the following location: /usr/sap/<SID>/D00/gcts.
Note that the <sid>adm user requires write access in this directory.
If you use multiple application server instances, the directory must be on a shared directory to avoid inconsistencies and
data loss. To share directories between application server instances, you can use Network File System (NFS), or Server
Message Block (SMB). A separate share is required for every individual ABAP system in your landscape.
 Example
Example of a shared directory: /usr/sap/<my-shared-directory>/<SID>/gcts.
 Note
The working directory serves as the local Git repository of your ABAP system. Remember the path to the working
directory. You’ll need to enter it when you con gure gCTS. For more information, see Enable Git-Enabled Change and
Transport System in an ABAP System.
You've opened ports 22 and 443 for outgoing communication.
Port 22 is required for SSH communication between the Git client on the operating system of the ABAP server
and the remote repository on the Git server.
Port 443 is required for the secure communication (HTTPS) between the ABAP runtime and the remote
repository on the Git server.
This is custom documentation. For more information, please visit the SAP Help Portal
22
11/15/2023
Prerequisites: Git Server
System administration users who con gure gCTS, as well as development users who work with it, should have at least
basic knowledge about using Git as a version-control system. To use speci c gCTS functions, more advanced Git
knowledge is required. For more information about relevant Git knowledge when working with gCTS, see References to
Git Documentation.
You have a user account on a Git server, for example GitHub.
You have a remote Git repository on a Git server.
The repository must not be empty. It must at least contain a README le.
All users who need write access to the repository (for example, when pushing their developments to the repository),
must be entered as collaborators in the repository, or they must belong to a team that has sufficient permissions to
access the repository.
The user who schedules the gCTS observer job must also be a collaborator in the repository. This is the user who enables
gCTS in the ABAP system. We recommend that you use a technical user in the ABAP system to schedule the observer
job. To be able to set authentication of this user to the Git server, we recommend that you create a technical user on
your Git server.
For more information, see Enable Git-Enabled Change and Transport System in an ABAP System.
All users who need write access in remote repositories, and users of private repositories, must specify authentication to
the Git server in the gCTS app. We recommend that you use user-speci c authentication. For this, all ABAP users,
including the technical user, require a user account on the Git server. For more information, see Set User-Speci c
Authentication.
Prerequisites: Communication Between the Components of gCTS
Different components are involved in gCTS. You must enable the communication between them in a secure way, using
Secure Socket Layer (SSL) certi cates in all relevant components. For more information, see Security for Git-Enabled
Change and Transport System.
If you use a communication proxy, gCTS requires the proxy settings to be con gured in the following locations:
ABAP system
For more information, see Con guring a Proxy in the Connectivity section of the ABAP platform documentation.
Operating system
If you've con gured a communication proxy on the ABAP system, you must also con gure it on the operating
system. For more information, refer to the corresponding documentation of your operating system.
Java environment
By default, the Java environment uses the proxy con gured on the operating system. If you've con gured it on the
operating system, no additional con guration is necessary for gCTS.
Related Information
Components of Git-Enabled Change and Transport System
Security for Git-Enabled Change and Transport System
References to Git Documentation
Authorization Concept in gCTS
All functions in gCTS are safeguarded by authorization checks at multiple levels.
This is custom documentation. For more information, please visit the SAP Help Portal
23
11/15/2023
Only users with the relevant authorizations can execute speci c tasks in gCTS.
Authorizations in the ABAP System
With the help of authorizations in the ABAP system, you can specify whether users are allowed to perform administrative,
repository-related, or development-related tasks in gCTS.
Depending on the gCTS roles and authorization objects assigned to them, users only see the functions for the tasks that they're
allowed to run. As a result, the gCTS app looks different for each user, depending on their authorizations .
SAP provides ABAP roles for the different gCTS user types Super Administrator, System Administrator, Repository
Administrator, and Developer. Each role has the appropriate authorizations for different tasks in gCTS. In most cases, it's
sufficient to grant user authorizations by assigning copies of roles. If the roles don't suit your needs, you can assign the gCTS
authorization objects individually according to your requirements.
The authorizations are required in each client in which you work with gCTS.
For more information, see Roles in gCTS and Authorization Objects in gCTS.
 Note
The gCTS authorizations are required for gCTS tasks, in addition to other authorizations that users may need, depending on
their tasks. For example, users may need authorizations to do ABAP development, to create Git repositories using a new
vSID, or to assign members to teams. For more information about authorizations in the CTS, see Authorization Concept in
the CTS.
The authorization trace is available to nd out which authorizations are required for speci c tasks. For more information, see
Using the System Trace to Record Authorization Checks (Transaction STAUTHTRACE).
Collaboration Permissions in the gCTS App
Depending on the role or authorizations users have in the ABAP system, it can be necessary to grant them further collaboration
permissions for individual local repositories to which they need access, for example for private repositories.
Collaboration permissions can be assigned in the gCTS app. They can be granted to individual users, or teams, when you add
users as collaborators to a repository. With collaboration permissions, users can view and run additional functions in speci c
repositories.
For more information, see: Collaboration Permissions.
Permissions on the Git Server
To work with Git repositories, every ABAP user also requires a user on a Git server as described in the Prerequisites: Git Server
section under Prerequisites for the Git-Enabled Change and Transport System.
ABAP users need to be mapped and authenticated to users on the remote Git server. To do this, gCTS supports different
authentication options. We recommend that you use token-based authentication. For more information, see Set User-Speci c
Authentication.
For access to a speci c repository, the following users must be either owners or collaborators in the remote repository, or they
must belong to a team that has access to the repository:
All users who need read and write access to a repository on the Git server (for example, when pushing their
developments to the repository).
This is custom documentation. For more information, please visit the SAP Help Portal
24
11/15/2023
The user who has scheduled the gCTS observer job. By default, this is the user who has enabled gCTS in the ABAP
system. We recommend that you use a technical user for the observer job. For more information, see Enable Git-Enabled
Change and Transport System in an ABAP System.
Roles in gCTS
Using roles you can grant authorizations based on tasks that users need to perform in gCTS.
Authorization Objects in gCTS
The gCTS authorization object S_GCTS_SYS is available to control the authorizations of gCTS users.
Collaboration Permissions
Collaboration permissions allow gCTS administrators to grant users permissions for Git repositories on ABAP systems.
Example: Distribution of Authorizations in a gCTS Project
The following is an example of how authorizations can be distributed in a team that works with gCTS:
Related Information
Security for Git-Enabled Change and Transport System
Roles in gCTS
Using roles you can grant authorizations based on tasks that users need to perform in gCTS.
gCTS provides prede ned roles that can be assigned to users depending on the tasks they need to perform.
The SAP_BC_GCTS_ADMIN role combines all authorizations required to work with gCTS, including the con guration of gCTS.
The other gCTS roles contain authorizations required for speci c tasks. Note that they build upon each other. If you want to
grant comprehensive authorizations to users using these roles, you must assign them multiple gCTS roles.
Overview of Roles
Technical Name of Role
Name of Role
Description of Functions
SAP_BC_GCTS_ADMIN
gCTS: Default
gCTS super administration role with authorizations for all gCTS tasks on
Template for
system and repository level. This role contains authorizations required for
Admin
con guring gCTS and con guring Git repositories on the ABAP system. Use
this role for super administration users, if you don't need to restrict the
authorizations for gCTS in your company. You can also use it, when testing the
usage of gCTS.
This role contains the gCTS authorization object S_GCTS_SYS with eld
ACTVT = All Activities.
In addition, it contains authorizations of the CTS authorization objects
S_CTS_ADMI, S_CTS_SADM, and S_TRANSPRT as well as authorizations to
create and release jobs (S_BTCH_ADM and S_BTCH_JOB) that are required
to schedule the gCTS observer job.
This is custom documentation. For more information, please visit the SAP Help Portal
25
11/15/2023
Technical Name of Role
Name of Role
Description of Functions
SAP_BC_GCTS_SYSTEM_ADMIN
gCTS: System
gCTS administration role with authorizations to perform gCTS tasks on
Administrator
system level, such as create, edit, and delete system con guration
parameters. This role contains authorizations for recurring system
administration tasks.
This role contains the gCTS authorization object S_GCTS_SYS with eld
ACTVT = All Activities.
 Note
In addition, to generally execute tasks on repository level, users
require the authorizations of the
SAP_BC_GCTS_REPOSITORY_ADMIN and
SAP_BC_GCTS_REPO_DEVELOPER roles.
To execute tasks in individual repositories, users require
collaboration permissions in the repositories.
SAP_BC_GCTS_REPOSITORY_ADMIN
gCTS:
gCTS repository administration role with authorizations for gCTS tasks on
Repository
repository level, such as create, edit, and delete Git repositories on the ABAP
Administrator
system, and execute write operations in repositories, such as push and pull
commits. Users with this role assigned can't assign collaborators or add or
change repository con guration parameters.
This role contains the authorizations of the authorization objects
S_CTS_ADMI, S_CTS_SADM, and S_DATASET.
This role delivers the gCTS authorization object S_GCTS_SYS in an inactive
mode. To grant all authorizations for repository administration tasks, activate
it in your copied role with ACTVT = 34 (Write), and 33 (Read). For more
information, see Authorization Objects in gCTS.
SAP_BC_GCTS_REPO_DEVELOPER
gCTS:
gCTS development role with authorizations to execute Git operations for own
Repository
Git repositories on the ABAP system, such as push and pull commits.
Developer
This role contains the authorizations of the authorization objects S_RFC,
S_SERVICE,S_CTS_ADMI, S_CTS_SADM, S_DATASET, and S_TRANSPRT.
Users who have this role assigned can create Git repositories on the ABAP
system. To collaborate in repositories of other users, they require additional
collaboration permissions.
Assign roles using Managing Roles.
 Note
Don’t assign any role directly, but instead assign a copy of the role to the users. For more information, see Changing
Standard Roles.
If you want to assign the authorizations individually, check the required role for elds and values of the individual
authorization objects, or use the authorization trace to nd out which authorizations are required for the required tasks. For
more information, see Using the System Trace to Record Authorization Checks (Transaction STAUTHTRACE).
Related Information
Authorization Objects in gCTS
Collaboration Permissions
Authorization Objects in the CTS
This is custom documentation. For more information, please visit the SAP Help Portal
26
11/15/2023
Authorization Objects in gCTS
The gCTS authorization object S_GCTS_SYS is available to control the authorizations of gCTS users.
S_GCTS_SYS
The authorization object S_GCTS_SYS is available for on-premise scenarios. It is delivered as part of the
SAP_BC_GCTS_ADMIN, and SAP_BC_GCTS_SYSTEM_ADMIN roles, and in an inactive mode as part of
SAP_BC_GCTS_REPOSITORY_ADMIN. The eld ACTVT (Activity) controls the level of access a user has to a Git repository on
an ABAP system. The other elds of this authorization object aren't used. The following values are available for the ACTVT eld:
Description of Values of Field ACTVT of S_GCTS_SYS
ACTVT
Description
33 (Read)
Users have general Read permissions on system level and on repository level.
On the Repositories tab in the System view, users can view all repositories except for private repositories.
Users can create repositories using an existing vSID, and delete own repositories.
In repositories of other users, users can view all information on all tabs.
34 (Write)
Users have general Write permissions on system level and on repository level.
Users can view all repositories on the ABAP system including private repositories.
Users can create repositories using an existing vSID, even if the SYSTEM_RESTRICTION con guration
parameter is set to restricted.
Users can delete own repositories.
Users can view the other tabs in the System view. On the Teams tab, they can create new teams.
In repositories of other users, users can pull commits, create branches, push objects and commits, create
and delete tags and jobs.
70 (Administer)
Users have general Admin permissions on system level and on repository level.
Users can create, edit, and delete con guration parameters for systems.
Users have administration authorization for all Git repositories on the ABAP system.
Users can create, edit, and delete Git repositories on the ABAP system, even if the
SYSTEM_RESTRICTION con guration parameter is set to closed. Users can create repositories using a
new vSID.
The following conditions can in uence the authorizations granted by the authorization object S_GCTS_SYS:
The value of the gCTS system con guration parameter SYSTEM_RESTRICTION can further restrict the creation and
deletion of repositories on the ABAP system. For more information, see Con guration Parameters for Systems.
Owners of repositories always have Admin permission in their repositories, regardless of the authorizations of
authorization object S_GCTS_SYS.
For individual repositories, collaboration permissions with Admin, Write , or Read authorization can be granted. For more
information, see Collaboration Permissions.
To create repositories with a new vSID, in addition to S_GCTS_SYS with ACTVT = Administer, users need additional
authorizations to create non-ABAP systems and transport routes and to read and write les in the gCTS directory.
Overview: Authorizations of Authorization Object S_GCTS_SYS with SYSTEM_RESTRICTION = open
This is custom documentation. For more information, please visit the SAP Help Portal
27
11/15/2023
The following table provides an overview of the different levels of authorization of S_GCTS_SYS and the effect on the individual
tabs on the gCTS app. For more information about the effects of the different levels of authorization, see the previous table
Description of Values of Field ACTVT of S_GCTS_SYS.
Overview: Authorizations of Authorization Object S_GCTS_SYS with SYSTEM_RESTRICTION = open
S_GCTS_SYS
ACTVT= 70
ACTVT=34 (Write)
ACTVT=33 (Read)
(Admininster)
System view
Repository view
Repository tab
Admin
Write
Write
Con gurations tab
Admin
Write
None
Registry tab
Admin
Write
None
Teams tab
Admin
Write
None
Repository view header
Admin
Read
Read
Commits tab
Admin
Write
Read
Con guration tab
Admin
Read
Read
Activities tab
Admin
Write
Read
Branches tab
Admin
Write
Read
Log tab
Admin
Write
Read
Objects tab
Admin
Write
Read
Registry tab
Admin
Read
Read
Properties tab
Admin
Read
Read
Collaboration tab
Admin
Read
Read
Tags tab
Admin
Write
Read
Jobs tab
Admin
Write
Read
Other gCTS Authorization Objects
S_GCTS_R
The authorization object S_GCTS_R is available for Cloud scenarios.
 Note
This authorization object doesn't have any effect in on-premise systems.
S_GCTS_REP (obsolete)
The authorization object S_GCTS_REP contains the eld REPOSITORY. The value is the hash value of the repository ID. It
grants administration permission for the repository ID provided.
 Note
This authorization object is obsolete. If you've assigned it in an earlier release, you can continue to use it. However, don't
assign it to new users.
This is custom documentation. For more information, please visit the SAP Help Portal
28
11/15/2023
Use authorization object S_GCTS_SYS to provide general authorization for Git repositories on ABAP systems, or
collaboration permissions to grant permissions for individual repositories on ABAP systems to individual developers or
teams.
Collaboration Permissions
Collaboration permissions allow gCTS administrators to grant users permissions for Git repositories on ABAP systems.
Collaboration permissions are required for users to do certain tasks. For example, they're required for users who have the
authorizations of the SAP_BC_GCTS_REPO_DEVELOPER role assigned and want to work in private repositories.
Depending on the tasks they need to do, users with one of the following roles also require collaboration permissions:
SAP_BC_GCTS_SYSTEM_ADMIN
SAP_BC_GCTS_REPOSITORY_ADMIN
You can add collaboration permissions to individual users or teams by assigning them as collaborators to a repository with
Admin, Write , and/or Read permissions.
 Note
Users who have the authorizations of the SAP_BC_GCTS_ADMIN role assigned to them have collaboration permissions for
all Git repositories on the ABAP system by default.
The following collaboration permissions are available:
Owner (only available for individual collaborators)
The user who creates a repository on an ABAP system has Owner permissions by default. These are equal to Admin
permissions. Only one user can have Owner permissions in a repository. If you add a collaborator with Owner
permissions, the previous owner gets back the previous permissions. If the user was not previously a collaborator, the
user is removed from the repository as a collaborator.
Admin
Grants administration permissions in a Git repository on an ABAP system. Users can perform the following tasks:
Edit and delete a repository.
Create, edit, and delete con guration parameters of a repository.
Create, edit, and delete properties of a repository.
Unregister a repository, branches, and objects from the gCTS registry.
All tasks of the Write and Read permissions.
Write
Grants write access in a Git repository on an ABAP system. Users can perform the following tasks:
Work with branches in a repository.
Commit les in a repository.
Push objects to a repository.
This is custom documentation. For more information, please visit the SAP Help Portal
29
11/15/2023
Register a repository with the gCTS registry, and register branches and objects.
Read
Grants read access in a Git repository on an ABAP system. Users can perform the following tasks:
View all information on all tabs in a repository, even if it's private.
 Note
For repositories that were created on ABAP systems with the default value Visibility set to Public, this permission
isn't required because all users have read access.
Related Information
Con guration Parameters for Systems
Use the Collaboration Tab of a Repository
Authorization Concept in gCTS
Example: Distribution of Authorizations in a gCTS Project
The following is an example of how authorizations can be distributed in a team that works with gCTS:
Example
There's a team of 12 developers working on three development projects in the areas of Financial Management, Human Capital
Management, and Platform Services. Three repositories exist for the different projects: FIN_REPO, HCM_REPO, and PS_REPO.
Five developers work in Financial Management, ve in Human Capital Management, and two developers work in Platform
Services but contribute also to both Financial Management and Human Capital Management. There are two system
administrators: Admin1, and Admin2.
In the DEV system, the setup is as follows:
Admin1 has the authorizations of the administration role SAP_BC_GCTS_ADMIN. Admin1 has full authorizations
for all gCTS tasks.
Admin1 has enabled gCTS in the system. For this, Admin1 has scheduled the gCTS observer job and must be a
collaborator in all remote repositories. Admin1 doesn't require any additional collaboration permissions in the
repositories on the ABAP system, because these are automatically granted by the role.
Admin 2 has the authorizations of the SAP_BC_GCTS_SYSTEM_ADMIN, SAP_BC_GCTS_REPOSITORY_ADMIN
and the SAP_BC_GCTS_REPO_DEVELOPER roles. Admin 2 is responsible for the con guration of the repositories
in the system. Admin 2 has created the remote repositories on the company´s enterprise GitHub server, and has
assigned Admin1 and the relevant development users as collaborators to the remote repositories on the GitHub
server. Admin 2 creates the repositories on the DEV system, clones them, and sets additional con guration
parameters as required.
Admin 2 assigns the authorizations of the SAP_BC_GCTS_REPO_DEVELOPER role to all developers.
In addition, Admin 2 creates the following teams on the Teams tab in the gCTS app:
Team FIN: 5 FIN developers
Team HCM : 5 HCM developers
Team PS: 2 PS developers
This is custom documentation. For more information, please visit the SAP Help Portal
30
11/15/2023
On the Collaboration tab in the individual repositories, Admin 2 assigns the following teams with Write
permission:
Repository Financial Management : Team FIN and Team PS
Repository Human Capital Management : Team HCM and Team PS
Repository Platform Services: Team PS
All development users can now work in the repositories to which they're assigned, and can do tasks in their
repositories, such as to commit les, push objects, work with branches, create, edit, and delete properties. Only
Admin 1 and Admin 2 can do tasks that involve creating, editing, and deleting con guration parameters, or
deleting repositories from the ABAP system.
In TST systems, the setup can be done the same way.
In the PRD system, both systems administrators exist. Admin1 enables gCTS. Admin 2 creates repositories and pulls
commits. Development users either don´t have a user, or, if they have a user with the development role, they only have
Read permission to any repositories.
Moreover, to protect the production system from unwanted changes, the gCTS system con guration parameter
SYSTEM_RESTRICTION is set to closed.
The following graphic illustrates the distribution of authorizations of the team members in DEV and TST:
This is custom documentation. For more information, please visit the SAP Help Portal
31
11/15/2023
Con guring Git-Enabled Change and Transport System
Before you can work with Git-enabled Change and Transport System (gCTS), an administration user must do the following
con guration steps:
This is custom documentation. For more information, please visit the SAP Help Portal
32
11/15/2023
Please note that image maps are not interactive in PDF output.
Enable Git-Enabled Change and Transport System in an ABAP System
You can use the Wizard to Enable gCTS in Current System to perform the con guration steps required to enable Gitenabled Change and Transport System (gCTS) in your ABAP system.
Set User-Speci c Authentication
Specify authentication of your ABAP user to the Git servers where your repositories are hosted, and, if necessary, to the
gCTS registry server.
De ne ABAP Packages as Managed by Git-Enabled Change and Transport System
By assigning the transport layer available for gCTS to an ABAP package, you de ne that all objects developed in this
package are managed by gCTS.
Con gure the gCTS Registry
To con gure the gCTS registry, you declare one of your ABAP systems as the gCTS registry server, and then connect the
relevant ABAP development systems with the gCTS registry server by setting a gCTS system parameter.
Integrate the gCTS Registry with the Transport Organizer
By integrating the gCTS registry with the Transport Organizer (transactions SE01/SE09), you enable the option to assign
objects in transport requests to speci c Git repositories.
Enable Git-Enabled Change and Transport System in an ABAP
System
You can use the Wizard to Enable gCTS in Current System to perform the con guration steps required to enable Git-enabled
Change and Transport System (gCTS) in your ABAP system.
Prerequisites
The prerequisites described under Prerequisites for Git-Enabled Change and Transport System are ful lled.
The user who uses the wizard has the authorizations of the SAP_BC_GCTS_ADMIN role assigned to them.
 Recommendation
We recommend that you use a technical user as described under Prerequisites: ABAP System.
Context
This is custom documentation. For more information, please visit the SAP Help Portal
33
11/15/2023
In the wizard, you set the paths to the gCTS working directory for repositories, the Java executable of the Java runtime, and the
Git client executable abap2vcs.jar. To do this, you must know where they’re located.
 Note
You can use transaction AL11 to check the paths in SAP directories. However, it’s possible that the Java executable was
installed in a directory that isn't displayed in AL11, for example /usr/bin/java.
In addition, the wizard schedules an observer job and sets mandatory TMS parameters.
Procedure
1. Start the gCTS app on your ABAP system as described under Start the SAP Fiori App for Git-Enabled Change and
Transport Management System.
2. In the System view of the gCTS app, choose Enable gCTS.
The Wizard to Enable gCTS in Current System opens.
3. Enter the following data:
 Note
To move to a new step, in between the steps, choose Save, and select the next step.
Steps in Wizard
Description
1. gCTS Directory
gCTS requires a working directory to store les in local repositories in the le system of the
application server as described under Prerequisites: Operating System. Note that a shared directory
is required if you work with multiple application server instances.
Enter the path to the working directory of gCTS. The path must end with gcts.
 Example
$(SYSTEM/DIR_INSTANCE)/gcts (default)
/usr/sap/<SID>/D00/gcts
The value is saved as the value of the system parameter VCS_PATH.
2. Java Runtime
gCTS requires a Java runtime on the le system of the application server to run the Git client as
described under Prerequisites: Operating System. Enter the path to the Java executable of the Java
runtime. For ABAP systems on Unix platforms, the path must end with java. For ABAP systems on
Windows platforms, the path must end with java.exe.
 Example
java (default)
(Unix platforms): /usr/sap/<SID>/SYS/exe/run/jre/bin/java
The value is saved as the value of the system parameter JAVA_RUNTIME.
This is custom documentation. For more information, please visit the SAP Help Portal
34
11/15/2023
Steps in Wizard
Description
3. Git Client
The Git client (Java executable: abap2vcs.jar) is delivered as part of the SAP Kernel and is
available in the "exe" directory on the le system of the application server. Enter the path to the Git
client. The path must exist and end with abap2vcs.jar.
 Example
$(SYSTEM/DIR_CT_RUN)/abap2vcs.jar
/usr/sap/<SID>/SYS/exe/run/abap2vcs.jar
The value is saved as the value of the system parameter A2G_RUNTIME.
4. Git-Enabled CTS
gCTS requires a scheduled job as described under Prerequisites: ABAP System.
By default, the job is scheduled for the current user who is logged on to the gCTS app. Note that for
all write operations that are triggered for any repository on this system, this user must be entered as
collaborator in the repository, or the user must belong to a team that has access to the repository. For
more information, see Prerequisites: Git Server.
By default, the job is scheduled on the default application server. If you work with multiple
application servers, you can change the default application server. To do this, select the Change the
Application Server link, and enter a speci c application server. By default, the eld is blank.
To schedule the observer job and set the TMS parameters, choose Initialize System.
5. Summary and Check
This step contains an overview of the settings that you made in the previous wizard steps. It also
contains a link to the Health Check.
4. To check that the con guration is complete, choose Health Check.
5. To close the wizard, choose Close.
Results
gCTS is now enabled in your ABAP system, and the following parameters are set:
gCTS working directory: VCS_PATH
Java runtime: JAVA_RUNTIME
Path to Git client: A2G_RUNTIME
The Health Check checks for valid values in the System Con guration Checks. You can display the values of the
parameters on the Con gurations tab of the System view. To edit these parameters, use the Con gurations tab, or the
Enable gCTS wizard.
 Note
In general, edit the value of the VCS_PATH parameter only before you start working with Git repositories. If you want
to change the value after you’ve added objects to the Git repository, make sure that the directory on the operating
system is also moved to the new location.
The observer job SCTS_ABAP_VCS_IMPORT_OBSERVER is scheduled in the system.
The Health Check veri es this in the Git-Enabled CTS Check. To display more information about the scheduled observer
job, for example to see which user has scheduled the job, use transaction SM37. For more information, see Checking the
gCTS Observer Job.
Related Information
This is custom documentation. For more information, please visit the SAP Help Portal
35
11/15/2023
Con guration Parameters for Systems
Use the Health Check
Set Con guration Parameters for Systems
In the gCTS app, you can set con guration parameters for the ABAP system.
Context
By default, the required system parameters are set when you enable gCTS in the ABAP system. For more information, see
Enable Git-Enabled Change and Transport System in an ABAP System. If necessary, you can add additional system parameters.
You can also add repository parameters as system parameters to make them valid for all repositories of the ABAP system. If a
repository parameter is speci ed in a repository, the value of the repository takes precedence. For more information on
repository parameters, see Con guration Parameters for Repositories.
 Caution
It is not allowed to specify the following security-related repository parameters as system parameters:
CLIENT_VCS_AUTH_USER
CLIENT_VCS_AUTH_PWD
CLIENT_VCS_AUTH_TOKEN
CLIENT_VCS_SSH_KEY
Procedure
1. In the System view of the gCTS app, go to the Con gurations tab.
2. Choose Create.
3. Enter any character string of the parameter name in the input eld to activate the autocomplete function, or select the
parameter from the dropdown list.
For a list of parameters, see Con guration Parameters for Systems.
4. Enter the correct value in the Value eld, or select it from the dropdown menu.
If there's a checkbox, select or deselect it as required.
5. Choose Save.
Results
The parameter is added as a system parameter. It's used where applicable for all subsequent actions in all repositories in the
system, if no repository parameter exists that takes precedence.
Con guration Parameters for Systems
You can set the system parameters for gCTS on the Con gurations tab in the System view.
 Note
The A2G_RUNTIME, JAVA_RUNTIME, and VCS_PATH parameters are mandatory. When you use the Enable gCTS wizard to
con gure gCTS on your system, they're set in the process.
This is custom documentation. For more information, please visit the SAP Help Portal
36
11/15/2023
Con guration Parameter
Default Value
Description
Example/More information
A2G_RUNTIME
$(SYSTEM/DIR_CT_RUN)/abap2vcs.jar
Path to the Git client
/usr/sap/<SID>/SYS/exe
(Java executable:
abap2vcs.jar) in
the "exe" directory
on the le system of
the application
server
 Note
DIR_CT_RUN
corresponds to
the SAP system
pro le
parameter
DIR_CT_RUN.
JAVA_RUNTIME
java
Path to the Java
/usr/sap/<SID>/SYS/exe
executable of the
Java runtime on the
le system of the
application server
VCS_PATH
$(SYSTEM/DIR_INSTANCE)/gcts
Working directory of
/usr/sap/<SID>/D00/gct
gCTS on the le
system of the
application server
 Note
DIR_INSTANCE
corresponds to
the SAP system
pro le
parameter
DIR_INSTANCE.
SYSTEM_RESTRICTION
Open
Parameter to
Possible values:
restrict the creation
Open (default): Users
of repositories on
depending on their aut
the ABAP system
Restricted
Only users with a gCTS
repositories.
Closed
Local repositories can'
protect the system. Th
supported by pipelines
For more information, see Auth
This is custom documentation. For more information, please visit the SAP Help Portal
37
11/15/2023
Con guration Parameter
Default Value
VCS_REGISTRY_DESTINATION
Description
Name of the HTTP
connection to the
gCTS registry server
as speci ed in
transaction SM59 of
the current ABAP
system, or by direct
URL of the gCTS
Example/More information
Example of a connectio
Example of a direct UR
https://example.
If you use the gCTS registry, th
For more information, see Con
registry server.
Related Information
Set Con guration Parameters for Systems
Use the Health Check
gCTS administration users can use the Health Check function to check whether the con guration of Git-enabled Change and
Transport System (gCTS) is complete and correct in the ABAP system.
Prerequisites
To do a Health Check run, you must have the authorization object S_GCTS_SYS with ACTVT = 70 (Administer)
assigned.
To display the results of the previous health check run, no special authorizations are required.
 Note
The results of the User Permissions checks are valid for your user, not the previous user.
Context
Different checks are run as part of the Health Check. If there are con guration tasks still open, or if the con guration contains
errors, the Health Check displays warnings or errors for the respective checks. The Health Check is offered as the last step of
the Wizard to Enable gCTS in Current System.
By default, when you open the Health Check, cached results are displayed for the user who last ran a Health Check run except
for the User Permissions check, which is run for your user. If you choose Refresh Check, the checks are run for the user account
that you used to log on to the gCTS app.
Procedure
1. In the gCTS app in the System view, choose Health Check.
The check results are displayed in a new dialog box. The top section indicates how many checks resulted in Error,
Warning, or Success. If all checks have the same status, this distinction is not made. By default, all checks are displayed.
2. Optional: To rerun the checks for your logon user, choose Refresh Check.
Use this function if you've changed the gCTS con guration in the ABAP system, and you expect that the results of the
check have changed. If you just close the Health Check and open it again, only the cached results are displayed.
3. Optional: To display only checks that have resulted in a speci c status, select a status.
This is custom documentation. For more information, please visit the SAP Help Portal
38
11/15/2023
Select All to display all checks.
4. Check the results of the checks that have the statuses Warning or Error.
To display more information about a speci c check, click anywhere in the line of the check. The details of the check help
you nd out whether the check result is relevant for your work.
For more information about the individual checks, see Health Check - Details About the Checks.
5. To close the Health Check dialog box, choose Close.
Related Information
Authorization Objects in gCTS
Health Check - Details About the Checks
The Health Check allows you to check the status of con guration settings and permissions required for Git-Enabled Change and
Transport System.
Only users with gCTS administration authorization can do a Health Check run. Other users can only display the results of a
previous Health Check run.
 Note
The User Permissions checks are run for the current logon user and display user-speci c results.
User Permissions (User-Speci c) Checks
Because users who work with gCTS require authorizations depending on the tasks they need to perform, use the Health Check
function to see which permissions have been assigned to your user.
Category
Description
Transport Management
Authorizations in the Transport Management System (TMS) are required for the following tasks:
System
To create repositories on the ABAP system using new virtual non-ABAP systems (vSIDs).
If the ABAP system is a development system and a domain controller, vSIDs can be automatically
created when users create repositories on the ABAP system. If this authorization is missing, users can
use only existing vSIDs when creating repositories on this system.
To import objects from the remote Git repository to the ABAP system.
Imports take place, for example when a repository is cloned to the ABAP system, or when commits
are pulled to the ABAP system.
For this, the following authorization objects are required:
S_CTS_ADMI with eld CTS_ADMFCT = TABL or S_CTS_SADM with eld CTS_ADMFCT = TABL, eld
DESTSYS = <SID of ABAP system>, and eld DOMAIN = <transport domain>.
S_TRANSPRT with eld TTYPE = * and eld ACTVT = Add or Create, Change, Display
S_RFC with RFC_TYPE = All values, eld RFC_NAME = STPA, and eld ACTVT = All
activities
The authorization objects are part of the delivered role SAP_BC_GCTS_ADMIN.
This is custom documentation. For more information, please visit the SAP Help Portal
39
11/15/2023
Category
Description
File Access
File access authorizations are required to read and write les in the gCTS directory. For this, the authorization
object S_DATASET with eld PROGRAM = SAPLEPSF, eld ACTVT = Read and Write and eld FILENAME
= * is required. The authorization object is part of the delivered role SAP_BC_GCTS_ADMIN.
Change and Transport
Authorizations in the Change and Transport System are required to create transport routes. For this, the
System
authorization object S_CTS_ADMI is required. The authorization object is part of the delivered role
SAP_BC_GCTS_ADMIN.
Related Information
Authorization Concept in gCTS
About the vSID
System Con guration Checks
To con gure gCTS in your ABAP system, you use the Wizard to Enable gCTS in Current System to set the paths to the Java
runtime, the gCTS Git client, and the gCTS working directory. Use the Health Check function to check whether this con guration
was done correctly.
Category
Description
Java Runtime
This check determines whether the path to the Java executable of the Java runtime is set. The path is saved
as the value of the system parameter JAVA_RUNTIME. If this check displays the status Error, use the
Con gurations tab to set the correct path.
gCTS Git Client
This check determines whether the path to the gCTS Git client is set. The Git client (abap2vcs.jar) is a
command line tool that is delivered as part of the SAP Kernel. The path is saved as the value of the system
parameter A2G_RUNTIME. If this check displays the status Error, use the Con gurations tab to set the
correct path.
gCTS Working Directory
This check determines whether the path to the gCTS working directory is set. The path is saved as the value
of the system parameter VCS_PATH. If this check displays the status Error, use the Con gurations tab to
set the correct path.
Related Information
Enable Git-Enabled Change and Transport System in an ABAP System
Con guration Parameters for Systems
Status of Repositories Check
Use the Health Check function to check the statuses of all repositories that have been created on the ABAP system.
Category
Description
Status of Repositories
If one repository has the status ERROR, the result of this check is Error.
Related Information
Repository View in gCTS App
This is custom documentation. For more information, please visit the SAP Help Portal
40
11/15/2023
TMS Con guration Check
To create repositories on your ABAP systems, gCTS needs to know whether the ABAP system is con gured as a domain
controller in Transport Management System (TMS). Use the Health Check function to check this.
Category
Description
Domain Controller
This check determines whether the system is a domain controller. If the system is a domain controller, the
result of the check is Success. If the system is no domain controller, the result of the check is Warning. In this
case, validate that a vSID exists for each local repository on the ABAP system. If the system is a domain
controller, gCTS automatically creates the vSID, if necessary, when the repository is created on the ABAP
system.
Related Information
Con guring the Transport Domain Controller
About the vSID
SAP Kernel Checks
gCTS requires minimum versions of SAP Kernel components. Use the Health Check function to check whether the required
versions are available for the ABAP system.
Category
Description
Git Client Available
This check determines whether the Git client is available. The Git client (abap2vcs.jar) is a command line
tool that is delivered as part of the SAP Kernel. If this check displays the status Error, it's possible that the
path to the Git client isn't set correctly. See also the result of the gCTS Git Client check under System
Con guration.
For more information, see System Con guration Checks.
Git Client Executable
This check determines whether the Git client can be run. The Git client (abap2vcs.jar) is run on the
operating system and it needs a working Java environment. If this check displays the status Error, the Java
call doesn't work correctly. Possible reasons are:
Insufficient permissions of the <sid>adm user in the Java runtime or in the Git client.
Incorrect con guration of the Java runtime.
See also the result of the Java Runtime check under System Con guration.
For more information, see System Con guration Checks.
Git Client File Access
This check determines whether the Git client has read and write access to les in the gCTS working directory.
The gCTS directory is saved as the value of the system parameter VCS_PATH. If this check displays the
status Error, this indicates insufficient permissions of the <sid>adm user in the gCTS working directory or
insufficient permissions of the logon user. See also the result of the File Access check under User
Permissions.
For more information, see User Permissions (User-Speci c) Checks.
Java Environment
This check determines whether the Java environment is available. To run the Git client, a minimum version of
Available
a Java runtime is required, which isn’t automatically installed with the standard SAP Kernel. You must install it
manually. If the result of this check is Error, install a supported Java version.
For more information, see Prerequisites for Git-Enabled Change and Transport System.
This is custom documentation. For more information, please visit the SAP Help Portal
41
11/15/2023
Git-Enabled CTS Check
To con gure gCTS in your ABAP system, you use theWizard to Enable gCTS in Current System to schedule an observer job for
the observer program that is required for gCTS. Use the Health Check function to check whether this job was scheduled.
Category
Description
gCTS Observer Job
The gCTS observer program SCTS_ABAP_VCS_IMPORT_OBSERVER requires the job
SCTS_ABAP_VCS_IMPORT_OBSERVER to be scheduled for the program to run. The scheduled job regularly
checks for objects that need to be transferred to the Git server, and then transfers new and changed objects.
If the result of this check is Error, use the Enable gCTS wizard to schedule the job. It's done when you choose
Initialize System.
Related Information
Enable Git-Enabled Change and Transport System in an ABAP System
Connectivity Checks
Based on the repositories created on the ABAP system, gCTS runs a basic connection check of the ABAP server and the Git
client (Java) to the corresponding Git servers.
The result of the check is either Success or Warning. If the result is Warning, ask your system administration to check the
connection to the Git server.
Category
Description
ABAP Client
This check determines whether the ABAP server can connect to the server <Git server>.
Connection <Git
server>
Git Client <Git server>
This check determines whether the Git client can connect to the server <Git server>.
Web Services Checks
Use the Health Check function to check if the gCTS Web services are active in the ABAP system.
Category
Description
gCTS REST Service
The gCTS REST service cts_abapvcs must be active in the ABAP system. If the result of this check is
Error, activate the REST service in SAP GUI in transaction SICF.
gCTS OData Service
The gCTS OData service SCTS_GCTS_SRV must be active in the ABAP system. If the result of this check is
Error, activate the OData service in SAP GUI in transaction /IWFND/MAINT_SERVICE.
gCTS SAP Fiori Service
The SAP Fiori service bc_cts_git must be active in the ABAP system. If the result of this check is Error,
activate the SAP Fiori service in SAP GUI in transaction SICF.
Set User-Speci c Authentication
This is custom documentation. For more information, please visit the SAP Help Portal
42
11/15/2023
Specify authentication of your ABAP user to the Git servers where your repositories are hosted, and, if necessary, to the gCTS
registry server.
Prerequisites
For token authentication to Git servers: You have a valid personal access token for your Git server user with sufficient
authorizations.
For more information about how to do this in GitHub and the scopes required for gCTS, see Creating personal access
tokens in GitHub.
For authentication of your ABAP user to the gCTS registry server: You have a user in the central gCTS registry server, if
the current ABAP system isn't the registry server.
Context
Authentication to Remote Repositories
Authentication is required to the following remote repositories:
Remote repositories of development systems
Required for write operations in remote repositories, such as push commits to remote repositories.
Private remote repositories of all ABAP systems
You’re logged on to the gCTS app with your ABAP user. In the gCTS app, you set authentication details of your Git server user to
the Git server where the repositories are hosted in which you work. The authentication details are stored in the gCTS credential
store.
To do this, in the gCTS app, you specify the API endpoint of the Git server where the remote repository is hosted, and you select
an endpoint type. For authentication, you either provide a personal access token, or user and password authentication to the
Git server. If you work in multiple repositories hosted on the same Git server, only provide the details once on the ABAP system.
 Note
If you set user-speci c authentication, you don’t need to set authentication for individual repositories. If both user-speci c
and repository-speci c authentication are de ned, gCTS uses the user-speci c authentication.
Authentication to the gCTS Registry Server
In the following situations, authentication of your ABAP user is required for communication with the gCTS registry server:
As a system administrator, you con gure the gCTS registry in your ABAP system using a direct URL.
The gCTS registry has been con gured in your ABAP system using a direct URL, and you want to use it for your
repositories.
In this case, specify the endpoint of the gCTS Rest API of the central gCTS registry server as the API endpoint, and select the
Registry endpoint type.
For more information, see Con gure the gCTS Registry.
Procedure
1. In the gCTS app, in the System view, choose
(Manage settings of current user).
This is custom documentation. For more information, please visit the SAP Help Portal
43
11/15/2023
The Credential Store of ABAP User dialog opens.
2. To add an entry, choose Create Credentials.
3. Enter the URL to the API endpoint of the Git server where your remote repository is hosted.
For example, the API endpoint of Bitbucket is https://api.bitbucket.org/2.0/.
For repositories hosted on GitHub, or GitLab, it's sufficient to enter the URL to the Git server as the API endpoint, for
example, https://github.com. Make sure you select the relevant Endpoint Type in the next step.
For more information about supported API endpoints, see 2821718
in the Constraints Depending on Your Git Server
section.
For authentication of your ABAP user to the gCTS registry server, copy the URL that was de ned as the value of the
VCS_REGISTRY_DESTINATION system parameter in the System view on the Con gurations tab.
4. Select an Endpoint Type.
You have the following options:
Endpoint Type
Description
GitHub
To set the credentials of your GitHub user to the GitHub server, both public GitHub and any enterprise
instance of GitHub, select this option.
GitLab
To set the credentials of your GitLab user to the GitLab server, both public GitLab and any enterprise
instance of GitLab, select this option.
Registry
To set the credentials of your ABAP user to the gCTS registry server, select this option.
 Note
Use Basic authentication with this endpoint type.
Unknown
Select this option to set credentials to other Git servers, if necessary.
5. Select an authentication type.
You have the following options:
Authentication Type
Description
Token
Enter the personal access token of your Git server user.
Basic
Enter the user name and password that you use to log on to the speci ed API endpoint.
For authentication to Git servers, these are the user name and password of your Git server user.
For authentication to the gCTS registry server, these are your ABAP user name and password in
the gCTS registry server.
 Note
It depends on the Git server whether both options Token and Basic work correctly. For example, Basic authentication
has been deprecated by public GitHub.
6. Choose Save.
The authentication details are stored for this API endpoint. They’re added to the credential store of your ABAP user. You
see the new entry in the list.
7. Optional: Click anywhere in the row to display the details, or edit the entry.
This is custom documentation. For more information, please visit the SAP Help Portal
44
11/15/2023
For the endpoint types GitHub, GitLab, and Registry, the detail view also displays, if the credentials are valid.
For other Git servers, gCTS can't validate the credentials. However, if you've entered the correct API endpoint and
the correct credentials, authentication can still work. For known information about individual Git servers, see the
central gCTS SAP Note 2821718
, under Constraints Depending on Your Git Server.
a. Optional: To save a changed entry, choose Save.
b. Optional: To close the dialog without saving, choose Close.
8. Optional: To delete an entry, select the radio button of the relevant entry, and choose Delete.
Results
The credentials of your user are stored on the ABAP system for all speci ed API endpoints. They're used to authenticate your
user to all remote repositories that you work with and that are hosted on the Git servers for which you speci ed API endpoints.
If you've speci ed credentials to the gCTS registry server, they're used for the communication with the registry server.
Related Information
Repository-Speci c Authentication Options
De ne ABAP Packages as Managed by Git-Enabled Change and
Transport System
By assigning the transport layer available for gCTS to an ABAP package, you de ne that all objects developed in this package
are managed by gCTS.
At the start of a development project, packages are created for the ABAP development objects that will be created as part of
the project. When you create the package, you assign it to a transport layer. All ABAP development objects that you later create
in this package belong to the transport layer of this package and are transported along the transport routes that are set up for
this layer.
Before you use gCTS, you de ne which objects or packages you want to manage using gCTS. Decide whether you want to use
gCTS only for new development projects, or whether you also want to switch existing developments to gCTS. It’s important that
you assign the ABAP packages that you use with gCTS to transport layers that are different from the transport layers used for
classic CTS.
Use gCTS for New Development Projects
When you create new ABAP packages in your ABAP development system that you want to manage using gCTS, assign these
packages to the transport layer that was created in the following situations:
If the ABAP system is the transport domain controller: The transport layer is created when the repository is created on
the ABAP system. It’s generated from the value that was entered as vSID of the repository (Z+<vSID>).
If the ABAP system isn’t the domain controller: The transport layer is created as part of the Prepare ABAP Systems for
Repositories step.
Use gCTS for Existing Development Projects
To use gCTS for an existing ABAP package, proceed as described under How to Onboard Existing Developments to gCTS.
Con gure the gCTS Registry
This is custom documentation. For more information, please visit the SAP Help Portal
45
11/15/2023
To con gure the gCTS registry, you declare one of your ABAP systems as the gCTS registry server, and then connect the
relevant ABAP development systems with the gCTS registry server by setting a gCTS system parameter.
Prerequisites
In the ABAP system where you want to register objects with the gCTS registry, the required Business Add-In (BAdI) is
implemented as described under Integrate the gCTS Registry with the Transport Organizer. This is usually the
development system.
You've decided which ABAP system you want to use as the gCTS registry server.
You can use any SAP S/4HANA 2020 FPS 01 system or higher with the following characteristics:
The system has a high availability and high security precautions. For example, use a production system.
You've implemented all SAP Notes required for the version of the ABAP system that you want to use as the gCTS
registry server. For more information, see the gCTS registry SAP Note 3046346
.
If gCTS is not con gured in this system, the ICF service /sap/bc/cts_abapvcs is active in the system, and the
HTTPS port is open.
 Note
We recommend that you use HTTPS. However, it's possible to use HTTP.
The system doesn't need to be periodically reset.
You've decided whether you want to use a direct URL or an SM59 connection for the communication of the ABAP
development systems with the gCTS registry server.
You have the following options to specify the value of the gCTS system parameter VCS_REGISTRY_DESTINATION that
is used for communication with the gCTS registry server:
URL to the gCTS registry server
The URL must have the following format: <host of gCTS registry server>:
<port>/sap/bc/cts_abapvcs/registry/server.
If you use this option, the user who runs an action related to the gCTS registry is used for the communication with
the gCTS registry server. For example, the actions can be registering or unregistering a repository, a branch, or an
object. This way, every action related to the gCTS registry is logged for the user who ran it.
This option requires that all users who use the gCTS registry maintain their credentials to the endpoint of the
gCTS registry server. For this, they also need to have a user in the ABAP system that serves as the gCTS registry
server. For more information, see Set User-Speci c Authentication.
Name of an HTTP connection created in transaction SM59
The HTTP connection must have been created in transaction SM59 speci cally for communication with the gCTS
registry server.
For the user that is to be used for the HTTP connection, we recommend that you create a technical user in User
Maintenance (transaction SU01) of User Type : Service. The technical user must exist on the ABAP system that
serves as the gCTS registry server. However, the user doesn't have to exist on the other systems where you want
to use the gCTS registry.
If you use this option, the user speci ed in the SM59 connection is used for communication with the gCTS registry
server. This way, every action related to the gCTS registry is logged for the user speci ed in the SM59 connection.
The user that's used for the gCTS registry communication has the following authorizations assigned:
This is custom documentation. For more information, please visit the SAP Help Portal
46
11/15/2023
Authorization object S_CTS_ADMI with eld CTS_ADMFCT = EPS1.
Authorization object S_DATASET with eld ACTVT = 33 and 34, and eld PROGRAM = SAPLEPSF
For more information about assigning authorizations, see Managing Roles.
Context
To con gure the gCTS registry, connect the ABAP development systems that use the gCTS registry by setting the gCTS system
parameter VCS_REGISTRY_DESTINATION.
Do the con guration steps in all ABAP development systems in which you want to register objects.
Con gure the gCTS Registry Using a Direct URL
Procedure
1. In the gCTS app, in the System view, go to the Con gurations tab.
2. Add the con guration parameter VCS_REGISTRY_DESTINATION.
3. For the value of the con guration parameter, enter the URL in the following format:
<host of gCTS registry server>:<port>/sap/bc/cts_abapvcs/registry/server
4. Create credentials for your ABAP user to the gCTS registry server.
a. In the gCTS app, in the System view, choose
(Manage settings of current user).
b. Choose Create Credentials.
c. Enter the following information:
Field
More Information
API Endpoint
Enter the endpoint of the registry server in the following format:
<host of gCTS registry server>:
<port>/sap/bc/cts_abapvcs/registry/server
Endpoint Type
Select Registry.
Type
Select Basic.
User
Enter your ABAP user name on the gCTS registry server.
Password
Enter the password of your ABAP user on the gCTS registry server.
 Note
Inform all users who will work with the gCTS registry in this system that they must store their credentials to
the gCTS registry server as described in this step.
Con gure the gCTS Registry Using an SM59 Connection
Procedure
1. Create an HTTP connection to the gCTS registry server.
This is custom documentation. For more information, please visit the SAP Help Portal
47
11/15/2023
a. In transaction SM59, create an RFC connection of type HTTP connection to External Server. You can enter any
name for the connection, for example REGISTRY.
b. Enter the following values:
On the Technical Settings tab:
Field
Value
Host
Host of the application server of the ABAP system that serves as the gCTS registry server.
Port
Port of the gCTS REST service (cts_abapvcs) that was activated in the ABAP system
when gCTS was implemented. For more information, see App Implementation: Git-Enabled
Change and Transport System. To nd out the correct port, start transaction SICF, enter
cts_abapvcs as the Service Name, and choose Execute. On the next screen, from the
menu choose
Path Pre x
Goto
Port Information
.
Path to the gCTS REST service (cts_abapvcs):
/sap/bc/cts_abapvcs/registry/server
On the Logon & Security tab:
Field
Value
In the Logon with User
Choose Basic Authentication.
section:
Enter the name and the password of the user that you want to use for the registry
communication. For example, use the technical user mentioned in the Prerequisites
section.
If you've used the HTTPS
Choose Active for SSL to activate the SSL protocol for the connection.
port of the gCTS Rest
service, in the Security
Options section:
c. Save the HTTP connection, and run a connection test to make sure that the Status HTTP Response is 200.
 Note
Create the HTTP connection on all ABAP systems where the gCTS registry is used. These are usually all
development systems. If you use a development system as the gCTS registry server, perform the con guration
steps there too. Create an HTTP connection that points to the server itself.
2. In the gCTS app, in the System view, go to the Con gurations tab. Add the con guration parameter
VCS_REGISTRY_DESTINATION, and enter the name of the HTTP connection that you created in the previous step as
the value of this parameter, for example REGISTRY.
For more information, see Set Con guration Parameters for Systems.
Results
After you've done the con guration steps, the following tabs are visible in the gCTS app:
Registry tab in the System view
For more information, see Use the Registry Tab.
Registry tab in the Repository view
For more information, see Use the Registry Tab of a Repository.
This is custom documentation. For more information, please visit the SAP Help Portal
48
11/15/2023
If the HTTP connection isn't available, or if it doesn't work correctly, the Registry tab displays an error message No RFC
connection to registry found. This error is usually caused by communication issues, such as incorrect or missing credentials, an
incorrect URL, and so on.
Related Information
gCTS Registry
Integrate the gCTS Registry with the Transport Organizer
By integrating the gCTS registry with the Transport Organizer (transactions SE01/SE09), you enable the option to assign
objects in transport requests to speci c Git repositories.
To integrate the gCTS registry with the Transport Organizer, you must implement the Business Add-In (BAdI)
CTS_REQUEST_CHECK in all systems where you want to use the registry.
A sample implementation of this BAdI is provided on the SAP-samples space on GitHub at https://github.com/SAPsamples/s4hana-gcts-badi
. To do this, you clone the sample repository to your ABAP system, set the required parameters,
and then activate the BAdI implementation as described in the blog post Integrating gCTS with Transport Organizer processes
that is linked in SAP Note 3046346
.
 Caution
The coding of the sample implementation is provided without any warranty and isn't part of SAP standard support.
If you don´t use the sample implementation, implement the BAdI using the gCTS facade methods mentioned in the following
sample process. All facade methods are assigned to the package SCTS_ABAP_AND_VCS_API_FACADE.
A sample process of integrating the gCTS registry with Transport Organizer could look like this:
1. A transport request is created by a user, or by another external tool, such as Change Request Management of SAP
Solution Manager.
2. Objects are assigned to the transport request, for example using the Customizing transaction (SPRO).
3. A task of the transport request is released by a user.
4. The BAdI CTS_REQUEST_CHECK is triggered with the method CHECK_BEFORE_RELEASE.
5. The object list is analyzed and is checked with the gCTS registry.
(For this, the facade method SEARCH_OBJECTS of the class CL_CTS_ABAP_VCS_REGISTRY_FAC has been
implemented).
6. New, changed, or deleted objects are found and are committed to the relevant local repository.
(For this, the facade method COMMIT_REPOSITORY of the class CL_CTS_ABAP_VCS_REPO_FACADE has been
implemented.)
7. After a successful commit, the changes are pushed to the remote repository.
(For this, the facade method PUSH_REPOSITORY of the class CL_CTS_ABAP_VCS_REPO_FACADE has been
implemented.)
8. The BAdI run is completed.
This is custom documentation. For more information, please visit the SAP Help Portal
49
11/15/2023
Con guring Git Repositories
By con guring a Git repository on your ABAP system, you create a connection between your ABAP system and the remote Git
repository on the Git server.
This allows you to perform tasks, such as the following:
Store your development objects in your remote repository on the Git server and read them from there.
Push your developments to remote repositories and see the push action as a commit.
Work with branches.
Resolve con icts.
Con guration steps are necessary for every new Git repository that you work with. The following image map gives an overview
of the steps involved:
Please note that image maps are not interactive in PDF output.
Prepare ABAP Systems for Repositories
Do this step only if you want to start using Git-enabled Change and Transport System (gCTS) on a system that isn’t a
transport domain controller, and if the domain controller system isn't part of the gCTS landscape.
Create Git Repositories on an ABAP System
By creating a Git repository on an ABAP system, you make the repository known in the ABAP system and create
metadata for it.
Repository-Speci c Authentication Options
For the communication between ABAP development systems and remote Git repositories on the Git server, you must
provide authentication details. Private repositories on your Git server also require authentication.
Clone the Remote Git Repository to the ABAP System
By cloning the remote Git repository to the ABAP system, you import the content of the remote repository to your ABAP
system.
This is custom documentation. For more information, please visit the SAP Help Portal
50
11/15/2023
Prepare ABAP Systems for Repositories
Do this step only if you want to start using Git-enabled Change and Transport System (gCTS) on a system that isn’t a transport
domain controller, and if the domain controller system isn't part of the gCTS landscape.
Prerequisites
You want to start using gCTS on a system that isn’t your domain controller.
The domain controller of the system where you want to use gCTS isn't part of your gCTS landscape. That means, you don
´t want to use gCTS (create repositories) on the domain controller.
Context
gCTS requires at least one virtual non-ABAP system (vSID) on each ABAP system where you use gCTS. If the ABAP system isn’t
a domain controller, you have the following options to get this vSID:
If the domain controller is part of your gCTS landscape, the vSID is created automatically when a repository is created on
the domain controller system. To get the vSID also on systems that aren´t domain controllers, create a repository on the
domain controller system. As a result, the vSID is also available on the other systems of the transport domain.
For more information, see Con guring Git Repositories.
 Recommendation
We recommend that you use this option, if possible, for your scenario.
If your domain controller isn't part of your gCTS landscape, prepare your ABAP systems for usage with gCTS by manually
creating the non-ABAP system, a transport layer, and a transport route to the non-ABAP system.
The procedure is described in the following steps.
 Note
This procedure is required, for example, if you use gCTS integrated with Change Request Management of SAP
Solution Manager.
Procedure
1. Go to the transport domain controller of the system in which you want to use gCTS, and start transaction STMS.
2. Choose System Overview, and create a non-ABAP system.
To do this, choose
SAP System
Create
Non-ABAP System . Enter the following details:
Field
Description
System
Enter a three-character system ID (SID) for the non-ABAP system, which doesn’t yet exist in the TMS
con guration.
 Note
You’ll need to enter this SID as the value for vSID (virtual SID) when you register a repository on the
ABAP system.
For more information, see Create Git Repositories on an ABAP System.
Description
Enter a description.
This is custom documentation. For more information, please visit the SAP Help Portal
51
11/15/2023
Field
Description
Communication
System
Name
This value isn't relevant for gCTS.
By default, you can leave this entry unchanged. However, if your transport domain controller is lower
than ABAP Platform 1809 (SAP_BASIS 7.53), select a communication system that is at least on that
version. Otherwise, objects can’t be pushed to the Git server.
3. In the TMS Con guration for this non-ABAP system that you created, on the Transport Tool tab, set the parameter
NON_ABAP_SYSTEM to the value VCS.
By setting this parameter, you classify the system as a non-ABAP system of type VCS (version control system).
4. Create a transport layer.
 Note
If you use gCTS only for Customizing projects using the gCTS registry, you can skip this step because the request
types used for Customizing data don’t require a transport layer.
To create a transport layer, proceed as follows:
a. In transaction STMS, choose Transport Routes.
b. In the Transport Routes Editor, go to change mode and choose
Edit
Transport Layer
Create .
c. Enter a four-character transport layer ID, and a short description.
For the transport layer, you can use any four-character ID starting with Z. We recommend that you use the
following naming convention:
Z<SID of the non-ABAP system>.
All packages that you want to manage using Git must later be assigned to gCTS-speci c transport layers. We
recommend that you use a separate transport layer for each development repository.
For more information, see De ne ABAP Packages as Managed by Git-Enabled Change and Transport System.
5. Create a transport route using the transport layer whose target system is the non-ABAP system of type VCS.
 Note
If you use gCTS only for Customizing projects that use the gCTS registry, you can skip this step.
To do this, proceed as follows:
a. In change mode in the Transport Routes Editor, choose
Edit
Transport Route
Create .
b. Create a consolidation route, and select the following data from the input help:
Field
Description
Integration system
ABAP system that you want to use with gCTS.
Transport layer
Transport layer that you created before.
Consolidation system
Non-ABAP system that you created before (non-ABAP system of type
VCS).
6. Distribute the changes to the transport domain con guration so that you can use the virtual non-ABAP system as a vSID
on ABAP systems that aren´t domain controllers.
For more information, see Distributing the Transport Domain Con guration.
This is custom documentation. For more information, please visit the SAP Help Portal
52
11/15/2023
Related Information
Transport Layers and Transport Routes
Create Git Repositories on an ABAP System
By creating a Git repository on an ABAP system, you make the repository known in the ABAP system and create metadata for it.
Prerequisites
You have a remote Git repository on a Git server that you want to create on your ABAP system. For more information,
see Prerequisites: Git Server.
If your ABAP system isn't the transport domain controller: You've created a non-ABAP system. For more information, see
Prepare ABAP Systems for Repositories.
Procedure
1. In the System view of the gCTS app, choose the Repositories tab.
2. Choose Create.
3. In the Create Repository dialog box, enter the following details:
Field
Description
URL
URL to the remote Git repository on a Git server
For more information about the prerequisites for Git repositories, see Prerequisites: Git Server.
 Note
If you use a repository on GitHub, and you use the Copy function on the Clone dialog, make
sure that you remove the .git from the URL.
Don't use special or escape characters in the URL, for example %20.
Description
Description of the repository
By default, the description is derived from the URL that you entered previously. You can change it.
vSID
Three-character system ID of a virtual non-ABAP system required for gCTS
Example of vSID: DEV
If the ABAP system is the transport domain controller: Enter a three-character SID for the nonABAP system that is unique in your transport landscape.
The system automatically creates the non-ABAP system and a transport layer.
If the ABAP system isn't the transport domain controller, as value of vSID, enter the SID of the
non-ABAP system that you created as part of the Prepare ABAP Systems for Repositories step.
For more information, see About the vSID.
This is custom documentation. For more information, please visit the SAP Help Portal
53
11/15/2023
Field
Description
Role
Role of the repository
Possible values: Development | Provided
Development is the default value.
For repositories on source (development) systems, use Development. These are repositories into which
you want to transfer ABAP development objects (push commits). You can also pull commits to
repositories of type Development.
For repositories on target systems, use Provided. These are repositories where you want to retrieve
ABAP objects from (pull commits). You can't push commits to repositories of type Provided.
Type
Type of the repository
Possible values: Git | GitHub | GitLab.
GitHub is the default value.
For repositories of type GitHub, gCTS uses the GitHub API, which allows access to advanced functions.
Use this type if you use GitHub as the Git server. This is also valid if your company uses its own GitHub
Enterprise server.
For repositories of type GitLab or Git, some functions aren't available. For more information about any
restrictions, see the central gCTS SAP Note 2821718
Visibility
.
Speci es the visibility of the repository on the ABAP system
Possible values: Public | Private
Public is the default value and makes the repository visible to everyone.
You can restrict the visibility of the repository to your user only. To do this, set the repository to Private.
 Note
Users with one of the following authorizations nevertheless see Private repositories:
SAP_ALL authorizations
Authorizations of S_GCTS_SYS with eld ACTVT = Administer.
Any collaboration permission for the repository.
4. Choose Save.
Results
You've created the Git repository on your ABAP system. The repository has the status CREATED. The metadata of the
repository is created in the database of the ABAP system.
The system opens the Repository view of the new repository.
On the Con guration tab, the parameters CLIENT_VCS_URI and CLIENT_VCS_CONNTYPE are provided from the URL
that you entered in the Create Repository dialog box.
 Note
If you edit the value of the CLIENT_VCS_CONNTYPE parameter, check whether you must also edit the value of the
CLIENT_VCS_URI in the repository con guration. In addition, if you edit the CLIENT_VCS_URI parameter, the URL
of the repository isn't automatically changed. If necessary , also edit the repository URL.
The user who has created the repository is displayed as the owner of the repository and the creation date and time are
displayed in the header.
This is custom documentation. For more information, please visit the SAP Help Portal
54
11/15/2023
If necessary, you can edit the header data of the repository by choosing Edit in the header section. For more information,
see Edit Header Data of Local Repositories.
To clone the repository to the ABAP system, it's important that the basic values are correctly set.
Next Steps
1. If you haven't set authentication of your user, do this. For more information, see Set User-Speci c Authentication.
2. Clone the repository. For more information, see Clone the Remote Git Repository to the ABAP System.
Repository-Speci c Authentication Options
For the communication between ABAP development systems and remote Git repositories on the Git server, you must provide
authentication details. Private repositories on your Git server also require authentication.
The following authentication options are available in gCTS:
User-Speci c Authentication
The authentication details of a user executing an action are used for the communication between the ABAP system and remote
Git repositories. The gCTS credentials store is available in the System view of the gCTS app. It allows you to store the
authentication details of your ABAP user to all Git servers where repositories are hosted in which you work.
 Recommendation
We recommend that you use this option.
If you choose this option, you don’t have to set any repository-speci c authentication. For more information, see Set UserSpeci c Authentication.
Repository-Speci c Authentication
The authentication details of one user are used for the communication between the ABAP system and a Git repository on the
ABAP system. gCTS uses the authentication details of this user for all other users that execute actions in the repository.
If you choose this option, you must set the authentication details using a gCTS repository parameter separately in each
repository created on the ABAP system.
For more information, see Set Repository-Speci c Authentication.
Set Repository-Speci c Authentication
To set repository-speci c authentication, you set the authentication details of a speci c user using a repository con guration
parameter.
 Note
Use repository-speci c authentication in exceptional cases only, for example, if you encounter issues with User-Speci c
Authentication.
We recommend that you use a technical user on your Git server for repository-speci c authentication. The user must ful ll the
following prerequisites:
This is custom documentation. For more information, please visit the SAP Help Portal
55
11/15/2023
The user exists on the Git server that hosts the remote Git repository for which you want to set authentication.
The user has access to the Git repository. For example, the user is a collaborator in the Git repository.
For more information about how to do this in GitHub and the scopes required for gCTS, see Creating personal access
tokens in GitHub.
Only the technical user is used for authenticating to the Git server. Other users that work in the same repository don´t need
access to the remote repository.
To do this, proceed as follows:
1. In the gCTS app, in the Repository view, go to the Con guration tab.
2. You have the following options for authentication of the technical user:
For HTTPS connections (using the SSL protocol):
Token-based communication using a personal access tokenIf you use token-based communication
(required by most Git servers): The user has a valid personal access token with sufficient scopes
assigned.
Enter the personal access token of the technical user as the value of the con guration parameter
CLIENT_VCS_AUTH_TOKEN. For more information, see Con guration Parameters for Repositories.
User/password authentication
Enter the user name of the technical user as the value of the con guration parameter
CLIENT_VCS_AUTH_USER, and the password as the value of the con guration parameter
CLIENT_VCS_AUTH_PWD.
 Note
These authentication options are also available for HTTP connections. However, we recommend that you use
HTTPS.
For SSH connections:
By default, all connections in gCTS are created using the SSL protocol. If you want to use the SSH protocol, you
change the CLIENT_VCS_CONNTYPE parameter to the value ssh. To authenticate to the remote repository
using SSH, you use an SSH private key.
Enter an SSH private key as value of the con guration parameter CLIENT_VCS_SSH_KEY. For more information,
see Con guration Parameters for Repositories.
Results
The authentication details of the technical user are stored for the repository. They´re used for authentication to the remote
repository for all actions of all users that contribute to the repository.
If a user releases a change request, the following is logged:
On the Commits tab in the gCTS app:
If you use token-based communication (required by most Git servers): The user has a valid personal access token
with sufficient scopesThe ABAP user that released the change request is the Author of the commit.
For repositories on GitHub: If an email address is maintained for this user in the ABAP system, the email address
is the Author´s Email Address.
This is custom documentation. For more information, please visit the SAP Help Portal
56
11/15/2023
In the repository on the Git server: The ABAP user is displayed as the user that issued the commit. If an email address is
maintained, and the ABAP user has a user on the Git server that uses the same email address, the matching Git server
user is displayed as the user of the commit.
On the Log tab in the gCTS app: The user that has scheduled the gCTS observer job is logged as the user of the PUSH
action.
 Note
If you've set multiple con guration parameters for authentication, the following rules apply:
If the CLIENT_VCS_CONNTYPE parameter is set to ssh, the SSH key entered in the CLIENT_VCS_SSH_KEY
parameter is used for authentication.
If the CLIENT_VCS_CONNTYPE parameter is set to ssl, one of the following entities is used for authentication: the
token speci ed in the CLIENT_VCS_AUTH_TOKEN parameter, or the user speci ed in the CLIENT_VCS_AUTH_USER
parameter with the password speci ed in the CLIENT_VCS_AUTH_PWD parameter. If you’ve con gured all
con guration parameters by accident, the token is used.
If a repository-speci c authentication option is speci ed, and you've entered credentials for your user, the userspeci c credentials are used.
 Caution
It isn't allowed to set any authentication-related repository parameters as system parameters.
Examples of Repository-Speci c Authentication Settings
 Example
Authentication Settings with Personal Access Token
Con guration Parameter
Value
CLIENT_VCS_URI
https://github.com/gcts/repo_name
CLIENT_VCS_CONNTYPE
ssl
CLIENT_VCS_AUTH_TOKEN
b36902c0904fa13aad1a3b7dabc697661dd87xyz
 Example
Authentication Settings with User/Password
Con guration Parameter
Value
CLIENT_VCS_URI
https://github.com/gcts/repo_name
CLIENT_VCS_CONNTYPE
ssl
CLIENT_VCS_AUTH_USER
communication.user@example.com
CLIENT_VCS_AUTH_PWD
<Password of communication.user@example.com>
This is custom documentation. For more information, please visit the SAP Help Portal
57
11/15/2023
 Example
Authentication Settings with SSH Key
Con guration Parameter
Value
CLIENT_VCS_URI
git@github.com:user/repo_name.git
CLIENT_VCS_CONNTYPE
ssh
CLIENT_VCS_SSH_KEY
----BEGIN RSA PRIVATE KEY–---\nM..kjk\n----END RSA PRIVATE KEY
Related Information
Set User-Speci c Authentication
Clone the Remote Git Repository to the ABAP System
By cloning the remote Git repository to the ABAP system, you import the content of the remote repository to your ABAP
system.
Prerequisites
You’ve created a remote Git repository on your ABAP system and set up authentication as required.
Procedure
1. In the Repository view in the gCTS app, choose Clone Repository.
You can choose to run this function as a background job. To do this, select the dropdown arrow ( ) next to Clone
Repository and choose Clone in Background. For more information, see Schedule Background Jobs for gCTS Activities.
2. Con rm the subsequent dialog box.
The repository is cloned from the remote repository using the URL that you speci ed when you created the repository on
the ABAP system.
The cloning process does the following :
a. It copies the le structure of the remote repository to the le system on the application server of the ABAP
system (local repository).
b. By default, it exports the objects of the current commit from the local repository and imports them into the ABAP
database.
 Note
You can suppress the import by setting the VCS_NO_IMPORT repository parameter.
Note that, depending on the size of the repository, this process can take some time.
3. If the cloning is successful, the system displays a success message.
Results
The status of the repository changes from CREATED to READY.
This is custom documentation. For more information, please visit the SAP Help Portal
58
11/15/2023
On the Commits tab, the commits of the default branch in the remote repository are displayed. The current commit of
the local repository is updated to the latest commit of the default branch in the remote repository. This is indicated by
displaying it in bold characters.
A new directory with the repository name is created in the gcts working directory on the le system of the application
server. You can use transaction AL11 to check this. For the path to the gCTS working directory, check the value of the
VCS_PATH system con guration parameter.
You can check the result of a cloning process in the following places:
On the Log tab:
See the logs for the CLONE process.
On the Activities tab:
If objects were imported by the Clone activity, you can nd a log of the transport request that was created for the
import.
 Note
If the import generates a return code that is equal to or greater than 8, by default, gCTS returns an error message.
Nevertheless, the local repository is set to the latest commit of the cloned repository. This is required, because gCTS can't
determine the last successful commit during a cloning action. Carefully analyze the import errors.
To suppress the error message, you can set the VCS_IMPORT_ERROR_LEVEL con guration parameter to 9.
Related Information
Con guration Parameters for Repositories
Repository View in gCTS App
How to Onboard Existing Developments to gCTS
You can move your existing development projects from the classical CTS to gCTS.
Context
In general, you can move your existing development projects based on ABAP packages step by step to gCTS. The following is a
high-level overview of the steps that you must perform to onboard existing ABAP packages to gCTS.
Procedure
1. In your development system, complete your work on the ABAP packages that you want to use with gCTS. Make sure that
all developers who are contributing to the package also pause their work on the packages, until onboarding to gCTS is
completed.
2. Release all existing transport requests with objects of the packages, and transport them through your system landscape
using the classic CTS.
3. If not yet done, con gure gCTS on the development system:
a. Enable gCTS.
For more information, see Enable Git-Enabled Change and Transport System in an ABAP System.
b. Set authentication of your user to the Git server that will host the Git repository with the content of the ABAP
packages.
This is custom documentation. For more information, please visit the SAP Help Portal
59
11/15/2023
For more information, see Set User-Speci c Authentication.
c. If you want to use the gCTS registry for assigning objects that are part of the ABAP packages, con gure it.
For more information, see Con gure the gCTS Registry.
4. Decide which Git repository you want to use for the ABAP packages. You can use an existing Git repository, or create a
new one. You can combine multiple ABAP packages in one repository, or use separate repositories.
For more information, see Con guring Git Repositories.
5. If you want to use the gCTS registry, register the packages in the gCTS registry.
For more information, see gCTS Registry.
6. If you use gCTS without the gCTS registry, switch the transport layer of the package to the transport layer of the vSID.
For more information about vSIDs, see About the vSID.
For more information about transport layers in the classic CTS, see Assignment of Development Projects to Transport
Layers.
7. Before you can start using gCTS, manually push the entire package.
For more information, see Manually Push Objects.
 Note
This step is important, because it ensures that your Git repository contains complete objects before changes to these
objects (partial objects) are committed. gCTS supports partial objects. However, as a prerequisite, the complete
object must have been committed at least once.
Keep in mind that commits contain versions of objects. They aren't delta transports, even though transport requests
are used to record object changes. Importing a commit in a target system is a pull operation, which imports the delta
between the commit that is currently active in the target system and the commit that is being pulled.
For more information, see Pull Commits.
8. Continue your development in the ABAP packages. Inform other developers working on the package that they can
resume their work in the packages.
Result
You've onboarded existing packages to gCTS. As of now, your changed objects of released transports will be committed and
pushed to the respective Git repository.
For more information, see gCTS: Process Overview.
About Using gCTS for Customizing Data
You can use gCTS to manage your Customizing data using Git repositories.
Con guration
In general, to use gCTS for Customizing data, no speci c con guration steps are required.
However, we recommend that you use the gCTS registry for Customizing data. Con guration steps are required to use the gCTS
registry, including implementing a Business Add-In (BAdI). For more information, see gCTS Registry.
This is custom documentation. For more information, please visit the SAP Help Portal
60
11/15/2023
The repository on the ABAP system that you want to use for Customizing data must have Layout Version 3 at least. For more
information, see Set the Repository Layout.
 Recommendation
Use a separate repository for your Customizing data.
Context
If you use gCTS for Customizing data without using the gCTS registry: When creating Customizing requests, you must
enter the virtual non-ABAP system (vSID) as the target system in the Target eld of the request. This ensures the
transport along a gCTS-speci c transport layer and a push into a remote Git repository.
If you use gCTS for Customizing data using the gCTS registry: No transport layers are required. You must still enter a
vSID when creating the repository on the ABAP system. But you can use the same vSID for all repositories that use the
registry. You can use the same repository for all Customizing objects that you create in the system. When creating
Customizing requests, you don't need to enter a Target. You register the Customizing object in the gCTS registry. When
the transport request is released, gCTS assigns the object to the correct repository.
Important Notes
When you create commits with client-speci c Customizing data, make sure that you always create your commits in the
same client in the development system. To separate client-speci c Customizing within one repository, you can, for
example, create different branches for the Customizing objects of the individual clients.
 Example
Create branch 100 for Customizing objects of client 100.
Create branch 200 for Customizing objects of client 200.
When you pull a commit with Customizing data in a target system, the Customizing data is imported in the client that
you’re logged on to in the ABAP system. If you need to have the Customizing data in multiple clients, you have the
following options:
Log on to the ABAP system in the client in which you need the Customizing data. In the Transport Management
System (transaction STMS), you manually add the transport request that was created for the pull to the import
queue, and import it there.
For more information, see Adding a Change Request to the Import Queue.
Log on to the ABAP system in the client in which you need the Customizing data, and open the gCTS app in this
client. In the Customizing repository, on the Objects tab, use the Deploy function to import the Customizing data
in the current client.
 Note
Users who push or pull commits in multiple clients need to have permissions in all clients in which they work. For more
information, see Authorization Concept in gCTS.
Push the Current State of Customizing to a Git Repository
If you want to start using gCTS for your Customizing data at another time, or if you want to push the current state of the
Customizing in an ABAP system to a Git repository so that you can use it for other systems, you must make sure that the
Customizing objects are pushed to the Git repository. To do this, you have the following options:
This is custom documentation. For more information, please visit the SAP Help Portal
61
11/15/2023
Create a transport request of type Transport of Copies, and enter the virtual non-ABAP system (vSID) as target system
in the Target eld of the request.
Use the manual push function in the gCTS app to push Customizing objects to the Git repository. You can push both
individual Customizing objects and individual table entries, and the content of entire transport requests. For more
information, see Manually Push Objects.
Related Information
About the vSID
Using Git-Enabled Change and Transport System
The SAP Fiori app for Git-enabled Change and Transport System (gCTS app) provides access to the common tasks in gCTS.
Prerequisites
gCTS is con gured in your ABAP system.
For more information, see Con guring Git-Enabled Change and Transport System.
Context
The subsequent sections contain information about the tasks involved in using gCTS.
Start the SAP Fiori App for Git-Enabled Change and Transport Management System
The SAP Fiori-based application for Git-enabled Change and Transport Management System (gCTS app) supports you in
performing many gCTS-related tasks.
Using the System View
In the System view, you perform system-related tasks.
Working in a Repository
In the Repository view, you perform repository-related tasks.
Update ABAP Target Systems
To update an ABAP target system with the current state of development of the ABAP development system, you have
different options.
Integration of gCTS in CI Pipelines
To leverage the functions of Git-enabled Change and Transport Management (gCTS), we recommend that you integrate
gCTS into CI pipelines.
Start the SAP Fiori App for Git-Enabled Change and Transport
Management System
The SAP Fiori-based application for Git-enabled Change and Transport Management System (gCTS app) supports you in
performing many gCTS-related tasks.
Prerequisites
Your system administration has followed the implementation steps for the gCTS app described under App
Implementation: Git-Enabled Change and Transport System.
This is custom documentation. For more information, please visit the SAP Help Portal
62
11/15/2023
You have sufficient authorization to work with the gCTS app, including the authorizations to start SAP Fiori Launchpad.
For more information, see Authorization Concept in gCTS.
Procedure
The gCTS app enables you to perform tasks required to con gure and run gCTS. You can start it in the SAP Fiori Launchpad.
You can launch the SAP Fiori Launchpad in one of the following ways:
Using transaction code /ui2/flp in your ABAP system.
Using https://<host>:<port>/sap/bc/ui2/flp/.
You can add the application called Git-enabled CTS to your SAP Fiori Launchpad by using the app nder. The application is
available in the SAP: Application Services catalog.
System View in gCTS App
When the gCTS app starts, it opens in the System view where you can nd system-speci c information required to use gCTS and
a list of the Git repositories created on the ABAP system.
Header in System View
In the header of the System view, the following information is displayed:
Field
Description
Domain
Domain of the ABAP system
Status
Status of the ABAP system
Possible values: Available | Unavailable
If the status is Unavailable, check that your system con guration is correct, and that the system is up and
running.
Repository
Number of repositories created for this system
URL
URL to the OData service of gCTS
Client
Client in which the ABAP user is logged on to the ABAP system
Service
Path to the OData service of gCTS
Bottom Area in System View
In the bottom area of the System view, different tabs are available. For more information about the tasks that you can do on the
individual tabs, see Using the System View.
 Note
It is possible that tabs are hidden because of missing authorizations.
Repository View in gCTS App
This is custom documentation. For more information, please visit the SAP Help Portal
63
11/15/2023
When you select a repository in the System view, the Repository view opens.
Header in Repository View
In the header of the Repository view, the following information is displayed:
Field
Description
URL
Link to the URL of the remote repository on the Git server that was entered when the repository was created
on the ABAP system.
Type
Type of repository that was selected when the repository was created on the ABAP system.
vSID
System ID (SID) of the virtual non-ABAP system that was entered when the repository was created on the
ABAP system.
Branch
Active branch of the local repository
Current Commit
Link to the current commit in the local repository
 Note
The link only works when the current commit in the local repository already exists in the remote repository.
For example, if the commit hasn´t yet been pushed to the remote repository, the link doesn't work. You can
manually push local commits on the Objects tab. For more information, see Manually Push Local Commits.
Objects
Total number of objects in the local repository
Owner
Status
Status of the repository
Possible values: CREATED | READY | By default, this is the ABAP user who created the repository on the
ABAP system. You can change the owner of a repository.CHECKOUT| ERROR | MERGE
After a repository was created on the ABAP system, the initial value is CREATED.
After the remote repository has been cloned to the repository on the ABAP system or after you´ve
used the Update to Latest Commit function, the status is READY.
By default, this is the ABAP user who created the
repository on the ABAP system. You can change the owner of a (Pull selected commit to system’s
local repository (object difference is imported depending on the con guration)), the status is
CHECKOUT. If the repository is in this state, no commits to the local repository can take place. To
return to the current commit and status READY, use Update to Latest Commit.
If you’ve pulled any commit to the system using
If the repository is corrupt on the le system, the status is ERROR.
If the Git client detected con icts, the status is MERGE.
Role
Role of the repository that was selected when the repository was created.
Visibility
Visibility of the repository that was selected when the repository was created.
Bottom Area in Repository View
In the bottom area of the Repository view, different tabs are available. For more information about the tasks that you can do on
the individual tabs, see Working in a Repository.
 Note
It is possible that tabs are hidden because of missing authorizations.
This is custom documentation. For more information, please visit the SAP Help Portal
64
11/15/2023
Using the System View
In the System view, you perform system-related tasks.
Procedure
1. In the header of the System view, you can perform the following tasks:
Task
Function in the gCTS App
Description
Con gure gCTS in the ABAP
Enable gCTS
Opens the Enable gCTS wizard that guides you
system.
through the initial system con guration. For more
information, see Enable Git-Enabled Change and
Transport System in an ABAP System.
Check the con guration status of
Health Check
gCTS in the ABAP system.
Allows you to check whether the gCTS con guration in
your ABAP system is complete and correct. For more
information, see Use the Health Check.
Refresh the screen.
Set authentication of logon user to
Git server.
(Refresh data)
(Manage settings of current
user)
Performs a refresh of the screen.
Allows you to set authentication details for the remote
repositories in which you work. For more information,
see Set User-Speci c Authentication.
2. On the individual tabs, you can do other system-related tasks, including creating repositories.
Use the Repositories Tab
When you start the gCTS app, in the System view, the Repositories tab is opened by default. It contains a list of Git
repositories that have been created on the ABAP system.
Use the Con gurations Tab
The Con gurations tab in the System view contains a list of con guration parameters for systems.
Use the Registry Tab
The Registry tab contains a list of repositories in your system landscape that were registered in the gCTS registry.
Use the Teams Tab
On the Teams tab, you can get an overview of all teams that exist in the current ABAP system, create new teams, and
edit or delete existing teams.
Use the Repositories Tab
When you start the gCTS app, in the System view, the Repositories tab is opened by default. It contains a list of Git repositories
that have been created on the ABAP system.
Context
Get more information about all Git repositories that were created on the system.
Procedure
1. In the gCTS app, in the System view, choose the Repositories tab.
For each repository, the following information is displayed:
This is custom documentation. For more information, please visit the SAP Help Portal
65
11/15/2023
Column
Description
More Information
Repository ID
Unique ID generated from the repository Description when the
Create Git Repositories on an ABAP
repository was created.
System
 Note
The repository ID cannot be changed.
Name
Repository name derived from the repository Description when
Create Git Repositories on an ABAP
the repository was created.
System
Branches
Active branch of the local repository
Use the Branches Tab of a Repository
Commit
Current commit of the repository displayed as a link.
If you select the commit link, the commit
is opened in the connected Git server of
the remote repository.
Role
Type
vSID
Role of the repository that was selected when the repository
Create Git Repositories on an ABAP
was created.
System
Type of the repository that was selected when the repository
Create Git Repositories on an ABAP
was created.
System
vSID of the repository that was selected when the repository
Create Git Repositories on an
was created.
ABAP System
About the vSID
Visibility
Visibility of the repository that was selected when the
Create Git Repositories on an ABAP
repository was created.
System
2. On the Repositories tab, you can do the following tasks:
Task
Function in the
Description
gCTS App
Create a new repository.
Create
For more information, see Create Git Repositories on an ABAP
System.
Navigate to the Repository view of an
Open the Repository view of a repository using
existing repository.
anywhere in the repository row.
(Search)
Search
or by clicking
Filter the list of repositories by entering any character string in
the Search eld and choosing
(Search).
Use the Con gurations Tab
The Con gurations tab in the System view contains a list of con guration parameters for systems.
Procedure
1. In the gCTS app, in the System view, choose the Con gurations tab.
For each parameter, the following information is displayed:
Column
Description
This is custom documentation. For more information, please visit the SAP Help Portal
More Information
66
11/15/2023
Column
Description
More Information
Con guration Parameter
Name of the con guration parameter.
Con guration Parameters for
Value
Value of the con guration parameter.
Systems
 Note
If you've selected or deselected a checkbox to indicate the
value, the corresponding value is displayed. This can be
true | false, or X | <space>
Category
Category can be REPOSITORY or SYSTEM.
2. You can perform the following tasks:
Task
Function in the
Description
gCTS App
Set a con guration parameter.
Create
Set Con guration Parameters for Systems
Change the value of an existing
(Edit
Con guration
Parameter)
Choose
(Edit Con guration Parameter) in the parameter row.
(Delete
Con guration
Parameter)
Choose
(Delete Con guration Parameter) in the parameter
con guration parameter
Delete an existing parameter.
row.
Use the Registry Tab
The Registry tab contains a list of repositories in your system landscape that were registered in the gCTS registry.
Prerequisites
You have con gured the gCTS registry.
The tab is only displayed, if the registry is con gured. For more information, see Con gure the gCTS Registry.
Procedure
1. In the gCTS app, in the System view, choose the Registry tab.
For each registered repository, the following information is displayed:
Column
Description
Local Repository
Unique repository ID generated from the repository Description
The local repository is only displayed, if the repository exists on the ABAP
system.
URL
URL link to the remote repository.
Registered By
ABAP user name who registered the repository in the gCTS registry.
Date
Date and time of the registration of the repository in the gCTS registry.
This is custom documentation. For more information, please visit the SAP Help Portal
67
11/15/2023
2. For repositories that have been registered in the gCTS registry and cloned to the current ABAP system: Navigate to the
when the repository was created on the ABAP system.Registry tab in the Repository when the repository view of the
selected repository by clicking anywhere in the repository row.
Related Information
Create Git Repositories on an ABAP System
Register Git Repositories in the gCTS Registry
Use the Teams Tab
On the Teams tab, you can get an overview of all teams that exist in the current ABAP system, create new teams, and edit or
delete existing teams.
Prerequisites
You have the authorizations required to create a team.
To create teams, you need the authorization object S_GCTS_SYS with ACTVT = 70 (Administer) or 34 (Write) assigned.
To add members to teams, you need the authorization object S_USER_GRP with eld CLASS = SUPER and eld ACTVT =
03.
The authorizations are part of the SAP_BC_GCTS_ADMIN role.
Context
gCTS allows you to create teams, and assign the teams as collaborators to repositories. When adding a team to a repository,
you select the level of permissions that the team has in this repository. You can also add individual collaborators to a repository
and grant permissions to individual users.
To create a team, proceed as follows:
Procedure
1. In the gCTS app, in the System view, choose the Teams tab.
2. Choose Create Team.
3. Enter a name for your new team, and a description, and choose Save.
4. To add members to the team, select
(Edit Team) in the row of the team.
5. In the Edit Team dialog box, enter a name of an existing ABAP user in the Members eld, and choose Enter .
6. Repeat the previous step for all users that you want to add to the team.
 Note
Make sure that you enter names of ABAP users that exist in the ABAP system. gCTS only checks that the user exists,
when you save this dialog.
7. To save the changes to the team, choose Save.
Results
This is custom documentation. For more information, please visit the SAP Help Portal
68
11/15/2023
You've created a team.
Next Steps
To assign the team to a repository, go to the Collaboration tab of a repository.
Related Information
Use the Collaboration Tab of a Repository
Authorization Concept in gCTS
Working in a Repository
In the Repository view, you perform repository-related tasks.
Procedure
1. In the header of the Repository view, you can perform the following tasks:
Task
Function in the
Description
gCTS App
Clone the content of the remote
Clone Repository
repository to the ABAP system.
Edit the metadata of the repository.
For more information, see Clone the Remote Git Repository to
the ABAP System.
Edit
Opens a dialog box to edit the metadata of a repository. For
more information, see Edit Header Data of Local Repositories.
Delete the repository.
Delete
Deletes the repository on the le system and the metadata in
the ABAP database.
 Note
This function doesn’t delete the remote repository from the
Git server.
 Note
When deleting a remote repository, make sure you also
delete it on all systems where it's been cloned and used.
Issues will arise, if you create a new repository with the
same name, and you clone it to a system where the previous
repository still exists with different content.
Refresh the display.
(Refresh data)
Performs a refresh of the display.
2. On the individual tabs, you can do other repository-related tasks.
Edit Header Data of Local Repositories
In the gCTS app, you can edit the header data of existing local repositories, such as the description, the visibility in the
gCTS app, or the owner.
Use the Commits Tab of a Repository
The Commits tab contains a list of all commits of a Git repository in reverse chronological order.
Use the Con guration Tab of a Repository
This is custom documentation. For more information, please visit the SAP Help Portal
69
11/15/2023
The Con guration tab contains a list of con guration parameters for repositories that were de ned for the current
repository.
Use the Activities Tab of a Repository
The Activities tab contains a history of all activities that were performed in the local repository in reverse chronological
order.
Use the Objects Tab of a Repository
The Objects tab contains an overview of the ABAP objects in the active branch of your local repository.
Use the Branches Tab of a Repository
The Branches tab provides an overview of the branches of a repository. You can create new branches, compare the
object differences between a selected branch and the active branch, switch to selected branches, merge branches, and
delete existing branches.
Use the Log Tab of a Repository
gCTS logs all actions that are performed for a speci c repository.
Use the Registry Tab of a Repository
The Registry tab provides an overview of the objects of the current repository that have been registered in the gCTS
registry. You can also use it to register new objects in the gCTS registry.
Use the Properties Tab of a Repository
On the Properties tab of a repository, you can set dependencies and prerequisites of the repository, and change its
default layout properties.
Use the Collaboration Tab of a Repository
On the Collaboration tab, you can add teams or individual users as collaborators to the repository.
Use the Tags Tab of a Repository
The Tags tab provides an overview of the tags of a repository. You can create new tags, compare the object differences
of selected tags, activate tags, and delete existing tags.
Use the Jobs Tab of a Repository
The Jobs tab provides an overview of scheduled background jobs of a repository. It allows you to create new jobs, delete
existing ones, and navigate to the detailed log of a job.
Edit Header Data of Local Repositories
In the gCTS app, you can edit the header data of existing local repositories, such as the description, the visibility in the gCTS app,
or the owner.
Procedure
1. In the gCTS app in the Repository view, choose Edit.
The Edit Repository dialog box displays the metadata of the repository that was selected when the repository was
created on the ABAP system. It also displays the user who created the repository and the creation date and time.
2. Edit the values where necessary.
You can edit the values of all elds except for the vSID eld.
 Caution
Only edit the URL in exceptional situations, because this can lead to inconsistencies. If you have entered an incorrect
URL , in general, we recommend that you delete the repository from the ABAP system, and create a new one using
the correct URL.
3. Save your changes.
Results
You´ve edited the header data of the local repository. The date and time of the edit is logged on the dialog box, along with your
user.
This is custom documentation. For more information, please visit the SAP Help Portal
70
11/15/2023
Use the Commits Tab of a Repository
The Commits tab contains a list of all commits of a Git repository in reverse chronological order.
Context
The Commits tab is opened when you go to a repository in the gCTS app. It contains a list of commits.
By default, the commits that exist in the remote repository of the branch that is active in the local repository are displayed in
the list. A commit that is currently active in this branch in your local repository is displayed in bold.
For each commit, the following information is displayed:
Column
Description
Commit ID
Link to the commit on the remote repository
Author
Depending on where the commit was created, either the user on the Git server or the user in the ABAP system
is displayed as the author of a commit.
Author´s Email
Address
If no email address is maintained in the system for the ABAP user, a default email address is displayed.
 Tip
In some ABAP systems, the <sid>adm is displayed as the author of a commit, and a generated email
address of this user is displayed as the author’s email address. To ensure the correct ABAP user, gets
displayed the user´s email address must be entered in the User Maintenance (transaction SU01).
Date
Date and time when the commit was created
Message
The commit message allows you to identify a speci c commit. Note the following points:
If the commit was triggered by a released transport request or a task in the ABAP system, by default
the commit message contains the number of the transport and a short description. You can in uence
the message text using con guration parameters. For more information, see Con guration Parameters
for Repositories.
Commits that are generated by gCTS have a generated commit message.
For commits that you´ve created by committing les manually, your commit message is displayed.
Procedure
1. In the gCTS app, in the Repository view, choose the Commits tab.
2. You can perform the following tasks:
Task
Function in the
Description
gCTS App
Select a local or remote branch
Dropdown list
By default, the remote commits of the branch that is currently active in
whose commits you want to
with all
the local repository are displayed. From the dropdown list, you can select
display.
branches of the
the local branch, or any other existing remote or local branch.
repository
Search for all commits that match
(Search)
Enter any character string in the Search eld and choose
(Search).
a speci c character string.
This is custom documentation. For more information, please visit the SAP Help Portal
71
11/15/2023
Task
Function in the
Description
gCTS App
Pull the current commit from the
Update to
Pull the latest commit from the remote repository to the local repository
remote repository to the local
Latest Commit
on the le system, and import the object delta in the ABAP system.
repository on the ABAP system.
Sort the list of commits.
For more information, see Pull Commits.
(Sort)
By default, the commits are sorted by commit date, in descending order.
You can change the sort order.
Filter the list of commits.
(Set Filters)
You can lter the list of commits according to different criteria.
If a lter is set, the lter icon is highlighted, and a Filtered By row
indicates which lters are set. The lter settings are kept throughout the
current session, even when you switch to a different branch or repository.
To reset the lters to the default settings, in the Filter dialog box choose
Reset.
 Note
In the put elds, you can enter any character string that you want to
lter with.
Reset local repository
(Reset all
changes of the
local repository
to the selected
commit.)
Reset Local Repository
Compare a selected commit with
(Compare
differences
between the
objects of the
selected
commits.)
Compare Commits
the active commit.
Navigate to the commit in the
Select the link
remote repository on the Git
of the commit.
server.
 Note
The link works, only if the commit also exists in the remote repository
and not in the local repository. It's possible for a commit to exist only
in the local repository if, for example, gCTS’s automatic pull and push
behavior was disabled in this repository. For more information, see
Disable Automatic Pull and Push.
Pull a selected commit from the
remote repository to the local
repository on the ABAP system.
(Pull selected
commit to
system’s local
repository
(object
differences are
imported
depending on
the
con guration))
Pull Commits
Pull Commits
On the Commits tab in the gCTS app, you can manually pull commits to the current ABAP system.
Compare Commits
To nd out the object differences between two selected commits, you can use this function.
This is custom documentation. For more information, please visit the SAP Help Portal
72
11/15/2023
Reset Local Repository
You can use this function to discard all changes made in the local repository, and reset the local repository to a selected
commit.
Pull Commits
On the Commits tab in the gCTS app, you can manually pull commits to the current ABAP system.
Prerequisites
You have the authorization required to pull commits in a repository on the ABAP system.
Context
During a pull operation, the delta between From Commit and To Commit of the commit that you want to pull is imported and
activated in the ABAP system.
 Caution
The delta consists of the object differences between the commit that you want to pull and the commit that is currently
active in the system. If the currently active commit isn't the previous commit, the delta does not only contain the changed
objects of the commit that you want to pull, but also the objects of all commits in between. For more information, see About
Commits in gCTS.
By default, an import is run when you pull a commit. To make sure that your pull doesn't interfere with the work of other users,
you can in uence the import behavior using con guration parameters for repositories:
VCS_BUFFER_ONLY
VCS_NO_IMPORT
For more information, see Con guration Parameters for Repositories.
The following steps describe the manual pull of a commit in the gCTS app:
Procedure
1. In the gCTS app, in the Repository view, go to the Commits tab.
2. If your repository has multiple branches, make sure that the branch where you want to pull a commit is the active branch
in the current system.
3. Use one of the following functions:
Update to Latest
(Pull selected commit to system’s local repository (object difference is imported depending on the
con guration)) in the line of the current commit in the remote repository
 Note
You can choose to run the tasks as background jobs. To do this, select the dropdown arrow ( ) next to the respective
button.
Update to Latest: Choose
Pull commit: Choose
Update to Latest in Background.
Pull Commit in Background
This is custom documentation. For more information, please visit the SAP Help Portal
73
11/15/2023
For more information, see Schedule Background Jobs for gCTS Activities.
When gCTS detects updated les, it proceeds as follows:
a. It pulls the les to the local repository.
b. It converts the les to ABAP objects.
c. It imports the ABAP objects into the ABAP runtime.
 Note
Client-dependent data, such as Customizing data, is imported in the client in which you’re logged on to the
ABAP system where you started the gCTS app.
Before importing objects, gCTS checks whether any of the les that are to be imported during the action refers to
objects that are locked in an open change request. If objects to be imported are currently locked, they're displayed on a
dialog box. With the help of the list of locked objects, you can evaluate the impact of the import. An import will overwrite
locked versions in the ABAP system. It's a sensitive action that can result in data loss if objects are overwritten that
other users are currently working on.
4. If the Compare Object Differences dialog box is displayed and you want to proceed, con rm the dialog box.
Results
The system is set to the selected or the latest commit.
The Current Commit in the header displays a link to the commit that was pulled.
The commit that was pulled is displayed in bold characters because it's now the active commit of the local repository.
If you've used Update to Latest, the status of the repository is READY.
If you've pulled a selected commit, the status of the repository is CHECKOUT, even if you've pulled the latest commit of
the repository.
You can check the result in the following places:
On the Log tab:
See the logs for the PULL_BY_COMMIT process.
On the Activities tab:
See the status of the Pull activity and the log of the change request that was created for the import.
 Note
If the import generates a return code that is equal to or greater than 8, by default gCTS returns an error message, and the
local repository remains on the old commit, even though the import has run. In such an error situation, carefully analyze the
log of the request. To suppress the error message and classify the return code as tolerable, you can adjust the
VCS_IMPORT_ERROR_LEVEL con guration parameter. For more information, see VCS_IMPORT_ERROR_LEVEL.
Compare Commits
To nd out the object differences between two selected commits, you can use this function.
Prerequisites
This is custom documentation. For more information, please visit the SAP Help Portal
74
11/15/2023
You're in the gCTS app, on the Commits tab of a repository.
Context
 Recommendation
Use this function before you pull a commit.
Procedure
1. Select two commits that you want to compare with each other.
 Note
The sequence in which you select the commits determines the type of change.
2. Choose
(Compare differences between the objects of the selected commits.) .
Results
The system compares the objects of the selected commits. As a result, the system displays the objects that differ between the
commits and the type of the change (object is created, deleted, or modi ed). This function doesn't show detailed changes in
objects. For in-depth comparison, use the speci c commit comparison function offered by your Git provider.
Reset Local Repository
You can use this function to discard all changes made in the local repository, and reset the local repository to a selected commit.
Context
Use this function with caution in error situations in your local repository. All local changes that haven't been committed are
deleted in the process, and there's no option to recover them. For example, use the reset function, if you've started to resolve a
con ict, but you can't complete the con ict resolution.
This function includes the following actions:
1. It discards all changes made in the local repository that haven't been committed.
2. It sets the selected commit as the current commit of the local repository, but without importing objects to the ABAP
system.
This function corresponds to the Git function git reset --hard.
 Note
Resetting the local repository doesn't affect the ABAP system:
Changes in the ABAP system are kept and not discarded.
No imports take place in the ABAP system.
Changes to the repository con guration that are part of the selected commit aren't reset.
Procedure
This is custom documentation. For more information, please visit the SAP Help Portal
75
11/15/2023
1. In the gCTS app, in your repository, choose the Commits tab.
2. If you want to reset the repository to a commit that isn´t the latest, pull this commit to the ABAP system.
 Note
Because the reset function doesn´t run an import, a pull is required before the reset so that the objects of the
commit are imported in the local ABAP system.
3. Select the commit to which you want to reset the repository.
4. Choose
(Reset all changes of the local repository to the selected commit.).
5. On the subsequent message, choose Reset.
Results
The local changes of the repository are discarded. The selected commit is set as the current commit of the repository.
The action is logged in the gCTS logs. For more information, see Use the Log Tab of a Repository.
 Example
For example, you've started to resolve a con ict, but you've made an error. You've added the con icting le to the index of
the local repository. This means that you can't return to the con ict resolution editor to continue with a con ict resolution.
You haven't yet committed the result of the con ict resolution to the local repository. In this case, you can reset the
repository to the current commit, and repeat the con ict resolution. If it's impossible to resolve the con ict, you can pull an
earlier commit of the repository and reset the repository to this commit in order to reset the repository to a state without
any con icts.
Use the Con guration Tab of a Repository
The Con guration tab contains a list of con guration parameters for repositories that were de ned for the current repository.
Procedure
1. In the gCTS app, in the Repository view, choose the Con guration tab.
For each parameter, the following information is displayed:
Column
Description
More Information
Con guration Parameter
Name of the con guration parameter.
Con guration Parameters for
Value
Value of the con guration parameter.
Repositories
 Note
If you've selected or deselected a checkbox to indicate the
value, the corresponding value is displayed. This can be
true | false, or X | <space>
Category
Category can be REPOSITORY or SYSTEM.
2. You can perform the following tasks:
This is custom documentation. For more information, please visit the SAP Help Portal
76
11/15/2023
Task
Function in the gCTS
App
Description
Set a con guration parameter.
Create
Set Additional Con guration Parameters for
Repositories
Change the value of an existing con guration
parameter
Delete an existing parameter.
(Edit Con guration
Parameter)
Choose
(Delete Con guration
Parameter)
Choose
(Edit Con guration Parameter) in the
parameter row.
(Delete Con guration Parameter) in the
parameter row.
Set Additional Con guration Parameters for Repositories
When a repository is created on an ABAP system, the con guration parameters CLIENT_VCS_URI and
CLIENT_VCS_CONNTYPE are automatically set. You can add additional parameters, depending on your requirements.
Edit Con guration Parameters for Repositories
You can change the value of con guration parameters for repositories, and set them as global parameters.
Con guration Parameters for Repositories
You can set the following con guration parameters for repositories on the Con guration tab in the Repository view.
More Information About Con guration Parameters for Repositories
This topic contains additional information about speci c con guration parameters for repositories.
Disable Automatic Pull and Push
By default, when you release a transport request or a task that uses a gCTS-speci c transport layer, or when you use the
manual push function in the gCTS app, gCTS automatically pulls the latest changes from the remote Git repository from
the branch that is currently active in the system (without importing them in the ABAP system), creates a new local
commit, and pushes the commit to the remote repository.
Set Additional Con guration Parameters for Repositories
When a repository is created on an ABAP system, the con guration parameters CLIENT_VCS_URI and
CLIENT_VCS_CONNTYPE are automatically set. You can add additional parameters, depending on your requirements.
Prerequisites
You’ve created a Git repository on your ABAP system.
Context
To set additional con guration parameters for repositories, you use the Con guration tab of your repository.
 Note
The parameters that you de ne here are valid only for the current repository. If you want to de ne parameters that are valid
for all repositories of the current ABAP system, you can de ne them as system parameters. Note that the parameters that
are con gured as system parameters aren’t visible in the list of repository parameters of the individual repository. To check
them, go to the Con gurations tab in the System view. For more information, see Set Con guration Parameters for
Systems. If you’ve con gured the same parameters as repository parameters and also as system parameters, gCTS uses
the repository parameters.
Procedure
This is custom documentation. For more information, please visit the SAP Help Portal
77
11/15/2023
1. In the gCTS app, select the repository that you want to set parameters for.
2. In your repository, choose the Con guration tab.
3. Choose Create.
4. Enter any character string of the parameter name in the input eld to activate the autocomplete function, or select the
parameter from the dropdown list.
For a list of parameters, see Con guration Parameters for Repositories.
5. Enter the correct value in the Value eld, or select the checkbox, to set the value to true or X.
6. Choose Save.
Edit Con guration Parameters for Repositories
You can change the value of con guration parameters for repositories, and set them as global parameters.
Prerequisites
You have the permissions required to edit con guration parameters in the local repository.
To set a con guration parameter as global, you need write permission in the remote repository. This is required, since this
action creates a commit and pushes it to the remote repository. Otherwise, the push will fail.
For more information, see Authorization Concept in gCTS.
Context
On the Con guration tab of your repository, you can edit existing con guration parameters for the repository.
By default, when you set a parameter on an ABAP system, it's set as a local parameter. This means it's valid only on the local
system.
If you want to make the parameter available for all systems that the repository is cloned to, you can edit the parameter and set
the Scope to Global. This action creates a new commit, and the parameter is stored in the repository. When you clone the
repository to a target system, or when you pull the latest commit in a target system, the con guration parameter is pulled to
the target system. It's displayed on the Con guration tab in the Repository view.
 Note
If a global repository parameter is pulled to a target system where the same parameter already exists with a different value,
the local value remains unchanged.
To edit a con guration parameter for a repository, proceed as follows:
Procedure
1. In your repository, go to the Con guration tab.
2. In the row of the parameter that you want to edit, choose
(Edit Con guration Parameter).
3. For the Value eld, depending on the parameter, you have the following options:
If there's an input eld, enter the correct value.
If there's a checkbox, proceed as follows:
This is custom documentation. For more information, please visit the SAP Help Portal
78
11/15/2023
If you want to set the value to true, select the checkbox.
If you want to set the value to false, deselect the checkbox.
4. Optional: For the Scope eld, select the value Global.
5. Choose Save.
Results
A toast message tells you that the parameter was saved.
If you've set the Scope value to Global, the following actions are triggered:
A commit is created with the generated text:
add con guration <con guration parameter> <value>
If you've sufficient permissions in the remote repository, and you haven't disabled the automatic pull and push in the
ABAP system, the commit is pushed to the remote repository.
An entry is added in the .gcts.properties.json le of the repository with the following data:
"con gurations":[{"key":"<con guration parameter>", "value":"<value>"}]
Con guration Parameters for Repositories
You can set the following con guration parameters for repositories on the Con guration tab in the Repository view.
 Note
You can con gure repository parameters for individual repositories. For more information, see Set Additional Con guration
Parameters for Repositories.
If you want to con gure the same parameters for all repositories in your ABAP system, you can con gure them as system
parameters. For more information, see Set Con guration Parameters for Systems. Note that, if you've set a con guration
parameter as a system parameter, and you also specify it as con guration parameter for a speci c repository, this system
parameter value gets overwritten in the speci c repository.
 Caution
It is not allowed to specify the following security-related repository parameters as system parameters:
CLIENT_VCS_AUTH_USER
CLIENT_VCS_AUTH_PWD
CLIENT_VCS_AUTH_TOKEN
CLIENT_VCS_SSH_KEY
Con guration Parameter
Default Value
Description
Read-
Examples
Only
CLIENT_OS
tp
Speci es tp as the client that is
yes
used to communicate with the
operating system layer on this
system
This is custom documentation. For more information, please visit the SAP Help Portal
79
11/15/2023
Con guration Parameter
Default Value
Description
Read-
Examples
Only
CLIENT_PROXY_HOST
Proxy host used by the Git client
(Java) for outgoing network
communication
CLIENT_PROXY_PORT
Proxy port used by the Git client
(Java) for outgoing network
communication
CLIENT_TP_UMODE
1
tp option umode that is used
For more i
during an import
 Caution
Only change this value with an
explicit recommendation by
SAP support.
CLIENT_VCS
GIT
Speci es GIT as the version
yes
control system that is used to
communicate with a remote
repository
 Note
This parameter is obsolete.
CLIENT_VCS_AUTH_PWD
Password that is used by the
For more i
CLIENT_VCS_AUTH_USER to
Options.
communicate with a remote
repository when the repositoryspeci c authentication method
user/password is used for the
connection type ssl
CLIENT_VCS_AUTH_TOKEN (not
Personal access token created in
This param
recommended)
the Git server, for example GitHub,
However, w
which is used to communicate with
For more i
a remote repository. The token
Options.
must be created for a technical
user with access to the remote
repository.
CLIENT_VCS_AUTH_USER
User on the Git server that is used
to communicate with a remote
repository when the repositoryspeci c authentication method
communi
For more i
Options.
user/password is used for the
connection type ssl
CLIENT_VCS_COMMIT_DESCRIPTION
$(TRANSPORT/DOCUMENTATION)
Commit description syntax that is
For more i
used for a push into the remote
repository.
See:
CLIENT_VCS_COMMIT_MESSAGE
for values.
This is custom documentation. For more information, please visit the SAP Help Portal
80
11/15/2023
Con guration Parameter
Default Value
Description
Read-
Examples
Only
CLIENT_VCS_COMMIT_MESSAGE
[$(TRANSPORT/TRKORR)]
$(TRANSPORT/DESCRIPTION)
Commit message syntax that is
used for a push into the remote
repository
RepoID:
type: $
$(TRANS
timesta
documen
path: $
By default
request d
Transport
TR
DE
DO
TY
US
DA
TI
Al
Repository
ID
NA
System: (
Al
CLIENT_VCS_COMMIT_USER_MAIL
SAP_SCTS_AVCS_AUTHOR_MAIL
Name of a transport request
For more i
attribute that contains a user email
address that is used for a push
into the remote repository
CLIENT_VCS_COMMIT_USER_NAME
SAP_SCTS_AVCS_AUTHOR
Name of a transport request
For more i
attribute that contains a user name
that is used for a push into the
remote repository
CLIENT_VCS_CONNTYPE
ssl
Connection protocol that is used to
When you
communicate with a remote
automatic
repository.
Possible values:
For more i
System.
ssh
ssl
CLIENT_VCS_LOGLVL
warning
Granularity that is used for log
error, w
entries
This is custom documentation. For more information, please visit the SAP Help Portal
81
11/15/2023
Con guration Parameter
Default Value
Description
Read-
Examples
Only
CLIENT_VCS_SSH_KEY
----BEG
RSA PRI
SSH private key that is used to
communicate with a remote
repository for the connection type
When cop
ssh
must man
that the S
Repository
CLIENT_VCS_SSL_VERIFICATION
true
false
SSL veri cation for HTTPS
communication between Git client
and Git server
CLIENT_VCS_URI
https:/
URI that is used to clone a remote
repository.
For more i
This parameter is set when the
System.
repository is created.
CURRENT_COMMIT
Current commit ID of the
yes
b4af1bb
yes
Z<vSID>
repository
TRANSPORT_LAYER
Transport layer that de nes the
related objects or transport
requests for a particular
For more i
repository. When a repository is
created on a TMS domain
controller, the transport layer is
automatically created. In this case,
the value is displayed here as a
con guration parameter.
VCS_API_ENDPOINT
<space>
Technical API endpoint of a
Example:
repository.
VCS_AUTOMATIC_PULL
true
Latest commit is pulled
For more i
automatically from remote
repository before a commit is
executed
VCS_AUTOMATIC_PUSH
true
Commit is pushed automatically to
For more i
remote repository after a commit
is executed.
VCS_BUFFER_ONLY
<space>
No objects are imported into the
X
system, but a transport request is
generated and added to the buffer.
You can manually import the
transport request at a later point in
time.
VCS_ERROR_ROLLBACK
true
Local repository is rolled back to
the latest commit, if errors occur
for pull or switch branch actions.
VCS_IMPORT_ERROR_LEVEL
8
Minimum return code of an import
that gCTS displays as an error.
 Caution
false
For more i
Other mea
For more i
Use this parameter with caution
and in error situations only.
This is custom documentation. For more information, please visit the SAP Help Portal
82
11/15/2023
Con guration Parameter
Default Value
Description
Read-
Examples
Only
VCS_IMPORT_EXECUTION
Actions are triggered sequentially
after each import into the related
[{"acti
{"actio
system during a clone or a pull
operation. This operation raises an
exception if the execution of the
action has failed. (For example, if a
class is missing.)
VCS_IMPORT_TYPE
T
Type of generated transport
request that is used for a pull to
the target system.
VCS_LOG_STORAGE
<space>
De nition of a storage location for
K
For more i
db
the detailed process log of gCTS.
By default, the process log is
stored in the le system of the
application server. If the parameter
is set to the value db, the log is
stored on the database.
VCS_NO_CLONE
<space>
The remote repository isn’t cloned
X
to the ABAP system. No objects
are imported from the remote
repository to the ABAP system.
VCS_NO_IMPORT
<space>
No objects are imported or added
to the buffer during an update or
clone action.
X
Use this p
sure that y
ABAP sys
VCS_OBJECT_CALCULATION
full
De nes the scope of objects that
gCTS calculates for each commit.
full, wo
By default
repository
ABAP dat
improve p
object cal
calculatio
paramete
For more i
VCS_OBJECT_INDEX
full
De nes whether the result of the
object calculation (object index) is
written to the ABAP database for
each commit.
full, wo
By default
database.
restrict th
object ind
For more i
VCS_RESTRICTED_PUSH
<space>
Push into repository is allowed
X
only for particular transports (only
transport requests with the
transport request attribute
SAP_SCTS_AVCS_TARGET with
value [<REPO_ID>], or transport
request description pre x
[<REPO_ID>]).
This is custom documentation. For more information, please visit the SAP Help Portal
83
11/15/2023
Con guration Parameter
Default Value
Description
Read-
Examples
Only
VCS_TARGET_DIR (obsolete)
Target directory for object
yes
deployment within an existing
remote repository.
 Note
This parameter is obsolete.
Example:
If you use
applicatio
directory
directory
value you
This param
repository
see Set th
VCS_VALID_SYSTEM
Valid system IDs (SID) for target
S4D, S4
transport requests. Transport
requests that don’t match the SID
pattern are ignored for the push
into the remote repository.
More Information About Con guration Parameters for
Repositories
This topic contains additional information about speci c con guration parameters for repositories.
For an overview of all parameters that are available for gCTS, see Con guration Parameters for Repositories.
CLIENT_VCS_COMMIT_DESCRIPTION
Commit description syntax that is used for a push into the remote repository.
CLIENT_VCS_COMMIT_USER_MAIL
Name of a change request attribute that contains a user email address that's used for a push into the remote
repository.
CLIENT_VCS_COMMIT_USER_NAME
Name of a change request attribute that contains a user name that's used for a push into the remote repository.
VCS_ERROR_ROLLBACK
Local repository is rolled back to the latest commit, if errors occur for pull or switch branch actions.
VCS_IMPORT_ERROR_LEVEL
Minimum return code of an import that gCTS displays as an error.
VCS_IMPORT_TYPE
Type of generated change request that is used for a pull to the target system.
VCS_OBJECT_CALCULATION
De nes the scope of objects that gCTS calculates for each commit.
VCS_OBJECT_INDEX
De nes whether the result of the object calculation (object index) is written to the ABAP database for each commit.
Parameters and Values of VCS_OBJECT_CALCULATION and VCS_OBJECT_INDEX
To get the desired result, combine the values of the VCS_OBJECT_CALCULATION and VCS_OBJECT_INDEX
parameters.
CLIENT_VCS_COMMIT_DESCRIPTION
This is custom documentation. For more information, please visit the SAP Help Portal
84
11/15/2023
Commit description syntax that is used for a push into the remote repository.
By default, the change request number and the short description of the request are taken as the commit message, and the long
descriptions of the request and the tasks are concatenated in the commit description. And by default, Transport Management
System is set up in a way that users are free to decide whether to add long descriptions to requests and tasks.
You can ensure that users who release a task enter a long description to the task. To do this, proceed as follows:
1. In transaction SE03, under Administration, choose Global Customizing (Transport Organizer).
2. Change the value of check existence of task documentation at task release to Activate globally.
In this case, a task can only be released if a long description exists for it.
CLIENT_VCS_COMMIT_USER_MAIL
Name of a change request attribute that contains a user email address that's used for a push into the remote repository.
You can use the default SAP_SCTS_AVCS_AUTHOR_MAIL attribute, or de ne this attribute yourself.
By default, if a commit is created for a push action, gCTS takes the user name of the commit user from the ABAP user who
released the request. If you want to map the commit user to the user email on your Git server, you can use a request attribute.
De ne that the user who releases the request enters their email address as the attribute value. When the push into the remote
repository is triggered, the email address entered in the request attribute is written in the corresponding commit description.
For more information about request attributes, see Editing Attributes.
 Example
Entity
De ned Where
Value
CLIENT_VCS_COMMIT_USER_MAIL
In the gCTS app on the Con guration tab of a
SAP_SCTS_AVCS_AUTHOR_MAIL
con guration parameter
repository
SAP_SCTS_AVCS_AUTHOR_MAIL
Before releasing a request in transaction SE09, in
request attribute
the change mode of the request, assign the
john.doe@example.com
SAP_SCTS_AVCS_AUTHOR_MAIL attribute.
CLIENT_VCS_COMMIT_USER_NAME
Name of a change request attribute that contains a user name that's used for a push into the remote repository.
You can use the default SAP_SCTS_AVCS_AUTHOR attribute or de ne this attribute yourself.
By default, if a commit is created for a push action, gCTS takes the user name of the commit user from the ABAP user who
released the request. If you want to map the commit user to the user name on your Git server, you can use a request attribute
and de ne that the user who releases the request enters their user name as the attribute value. When the push into the
remote repository is triggered, the user name entered in the request attribute is written in the corresponding commit
description.
 Example
Entity
De ned Where
This is custom documentation. For more information, please visit the SAP Help Portal
Value
85
11/15/2023
Entity
De ned Where
Value
CLIENT_VCS_COMMIT_USER_NAME
In the gCTS app on the Con guration tab of a repository.
SAP_SCTS_AVCS_AUTHOR
SAP_SCTS_AVCS_AUTHOR request
Before releasing a request in transaction SE09, in change
John Doe
attribute
mode of the request, assign the
con guration parameter
SAP_SCTS_AVCS_AUTHOR request attribute.
VCS_ERROR_ROLLBACK
Local repository is rolled back to the latest commit, if errors occur for pull or switch branch actions.
By default, in gCTS, the VCS_ERROR_ROLLBACK parameter is true. This means that if there's an import error during a pull or a
switch branch action, gCTS automatically rolls back the commit that was activated for the action and reactivates the latest
commit of the previously active branch.
To change this behavior, you can set the VCS_ERROR_ROLLBACK parameter to false. As a result, even if import errors occur, the
local repository is set to the commit that was pulled (pull action), or to the latest commit of the branch that the repository was
switched to (switch branch action).
 Caution
The parameter settings only affect the state of the local repository. Even if import errors occur, the source code of the
commit that caused the error is always imported in the local ABAP system. It isn't rolled back.
If gCTS displays an import error, check the source code to nd out more about the cause of the error. Depending on your
situation, take the necessary steps to restore a correct state of the source code in your system. These can include:
Correcting the error in the development system and creating a new commit (by releasing the change request or task).
Then pulling the commit to the target system.
Using the Deploy function on the Objects tab with the Deploy Scope set to Current Commit to reimport all objects of
the repository. For more information, see Manually Deploy Objects.
If you're sure that the repository wasn't changed by other users after the import error occurred: Using the Deploy
function on the Objects tab with the Deploy Scope set to Last Repository Action to reimport the objects of the last
commit. For more information, see Manually Deploy Objects.
VCS_IMPORT_ERROR_LEVEL
Minimum return code of an import that gCTS displays as an error.
In gCTS, imports are triggered by a pull, clone or switch branch action. By default, gCTS displays imports with a return code 8 or
higher as an error.
 Note
This information also applies to activating tags of a repository.
If the con guration parameter VCS_ERROR_ROLLBACK remains on its default value true, gCTS behaves as follows:
Pull
This is custom documentation. For more information, please visit the SAP Help Portal
86
11/15/2023
gCTS imports the source code, and returns an error message. The local repository remains on the old commit.
Clone
gCTS imports the source code, and returns an error message. The local repository is set to the latest commit of the
cloned repository.
Switch Branch
gCTS imports the source code, and returns an error message. The selected branch is displayed as the active branch, but
the local repository stays on the old commit of the previous branch.
You can use this parameter to in uence the exception handling of gCTS when import errors occur. If you set the value of this
parameter to 9, gCTS will treat an import with a return code 8 as a success.
 Example
The following example is based on the assumption that VCS_ERROR_ROLLBACK remains unchanged.
You pull commit 1234567 to your test system. The import generates the return code 8 due to a syntax error in object ABCD.
gCTS doesn´t update the local repository to commit 1234567. In the transport log for the PULL activity on the Activities tab,
you nd out that you don´t need to x this object for your current testing. In this case, you can set the value to 9, and repeat
the pull of 1234567. The pull operation will return a success message, and the local repository will be set to commit 1234567.
 Note
To in uence the behavior of gCTS when import errors occur, you can use the VCS_ERROR_ROLLBACK parameter.
For more information, see:
Return Codes in the Transport Log
Pull Commits
Clone the Remote Git Repository to the ABAP System
VCS_IMPORT_TYPE
Type of generated change request that is used for a pull to the target system.
By default, a change request of type T (Transport of Copies) is used for the import into the target system. Transports of copies
can contain any object type. However, no delivery to another SAP system takes place.
You can change the type of the request to the value K (Workbench request). If you do this, a consolidation transport is created.
If transport routes are con gured to the follow-on ABAP system, as known from the classic CTS, requests that are pulled to the
system are forwarded to the follow-on system of your transport landscape.
Setting the VCS_IMPORT_TYPE parameter to K is useful, if you have a transport landscape in which you want to use both gCTS
and the classic CTS, and you want to make sure that requests are forwarded to the systems that use the classic CTS. You can
use gCTS for the rst systems in the transport landscape, for example development and test systems, and the classic CTS for
the follow-on systems, for example for the quality and production systems. In such a setup, you set the parameter to K in the
last system that still uses gCTS.
 Example
This is custom documentation. For more information, please visit the SAP Help Portal
87
11/15/2023
If you set the VCS_IMPORT_TYPE parameter to the value K in the gCTS con guration on the TEST system, requests of type K
are created, which can then be forwarded to the QA and the PROD systems.
VCS_OBJECT_CALCULATION
De nes the scope of objects that gCTS calculates for each commit.
When a remote repository is cloned to the ABAP system, the le and folder structure of the remote repository are copied to the
le system on the application server of the ABAP system (the local repository). By default, the objects are also imported in the
ABAP database.
Information about the objects of the local repository are displayed in the following places in the gCTS app:
The object count (number of objects) is displayed in the header of the repository.
The objects, including the object count, are displayed on the Objects tab.
To display the objects, gCTS accesses the local repository and reads the objects from there. This is necessary for each commit
to enable follow-up actions, such as displaying object differences between commits or branches. For large repositories, the
process of calculating and retrieving objects can be time-consuming, especially in repositories that contain Customizing objects.
Customizing can consist of multiple table contents, which further increases the runtime, as gCTS needs to compare differences
between the Git Repository and the database.
To accelerate the access to calculation results, gCTS creates an object index in the ABAP database by default. For each commit,
the results of the object calculation are stored in a database table. This allows gCTS to directly access the database table for
object information instead of accessing the local repository and reading the objects again.
Using the object index can signi cantly improve performance in stable repositories of normal size. Once the object index is
written to the database for a commit, gCTS no longer needs to recalculate the objects. This can enhance the performance of
gCTS. However, in repositories with a high number of daily commits, the advantage of the object index diminishes as it needs to
be regenerated for each new commit.
To adapt the object calculation according to your needs, you can modify the value of the repository parameter
VCS_OBJECT_CALCULATION.
 Note
When necessary, also change the value of the VCS_OBJECT_INDEX parameter. For more information, see Parameters and
Values of VCS_OBJECT_CALCULATION and VCS_OBJECT_INDEX.
The following values exist for VCS_OBJECT_CALCULATION:
This is custom documentation. For more information, please visit the SAP Help Portal
88
11/15/2023
Value
More Information
Full (default
gCTS calculates all objects of the repository. This includes both Customizing and ABAP workbench objects. Workbench
value)
objects are source code-based objects that are stored in the object directory (TADIR table).
Workbench
gCTS calculates the ABAP workbench objects of the repository.
Disabled
gCTS doesn't calculate any objects of the repository. In the repository header, the object count is displayed as N/A. No
objects are displayed on the Objects tab.
 Note
Changing the default value only affects read operations on objects of the repository.
For the following operations, a changed value is ignored because the default value is required:
Pull operations (clone, pull, switch branch)
Other gCTS operations that require object comparison functions, such as the comparison of objects or branches.
For these operations, object calculation takes place, regardless of the parameter value.
 Note
Changing the value impacts all subsequent commits in the repository.
Related Information
VCS_OBJECT_INDEX
VCS_OBJECT_INDEX
De nes whether the result of the object calculation (object index) is written to the ABAP database for each commit.
See also: VCS_OBJECT_CALCULATION
The following values exist for VCS_OBJECT_INDEX:
Value
More Information
Full (default
gCTS writes ABAP workbench and Customizing objects to the object index.
value)
Workbench
gCTS writes only ABAP workbench objects to the object index.
Only
Disabled
No object index is generated. gCTS recalculates the objects every time a repository is accessed.
 Note
Changing the default value only affects read operations on objects of the repository.
For the following operations, a changed value is ignored because the default value is required:
Pull operations (clone, pull, switch branch)
This is custom documentation. For more information, please visit the SAP Help Portal
89
11/15/2023
Other gCTS operations that require object comparison functions, such as the comparison of objects or branches.
For these operations, object calculation and index creation take place, even if the parameters have different values.
 Note
Changing the value impacts all subsequent commits in the repository.
Parameters and Values of VCS_OBJECT_CALCULATION and
VCS_OBJECT_INDEX
To get the desired result, combine the values of the VCS_OBJECT_CALCULATION and VCS_OBJECT_INDEX parameters.
Note the following points:
In general, we recommend that you keep the default values unchanged. If you encounter performance issues for read
operations in large repositories, administrators can change the settings.
In the following situations, we recommend that you keep the default values:
You have a stable repository, for example where one commit per day arrives in the repository.
You have an average-sized repository with less than 1000 objects.
In the following situations, if you experience performance issues, administrators can change the default values:
If you have a large team and multiple commits arrive in the repository per day, for example one commit every 10
minutes, or every hour. In this case, gCTS would need to create a new index for each commit, which takes time.
If you have a large repository, and gCTS takes a long time to calculate the index and write it to the database.
In general, if you've set the VCS_OBJECT_CALCULATION parameter to Disabled, setting the VCS_OBJECT_INDEX
parameter is unnecessary, because no objects are calculated and the index value doesn't impact the outcome.
Parameters and Values of VCS_OBJECT_CALCULATION and VCS_OBJECT_INDEX
VCS_OBJECT_CALCULATION
VCS_OBJECT_INDEX
Full
Workbench Only
Disabled
gCTS calculates ABAP
gCTS calculates ABAP
gCTS doesn't calculate any
workbench and Customizing
workbench objects only and
objects and doesn't generate
objects and generates an
generates an index of all
an index. The object header
index of all objects. The object
objects. The object header
displays N/A as the object
header displays the number of
displays the number of
count, and no objects are
all objects in the local
workbench objects only, and
displayed on the Objects tab.
repository, and all objects are
only workbench objects are
displayed on the Objects tab.
displayed on the Objects tab.
Workbench
gCTS calculates ABAP
gCTS calculates ABAP
gCTS doesn't calculate any
Only
workbench and Customizing
workbench objects only and
objects and doesn't generate
objects and generates an
generates an index of only the
an index. The object header
index of only the workbench
workbench objects. The object
displays N/A as the object
objects. The object header
header displays the number of
count, and no objects are
displays the number of all
workbench objects, and only
displayed on the Objects tab.
objects, and all objects are
workbench objects are
displayed on the Objects tab.
displayed on the Objects tab.
Full
This is custom documentation. For more information, please visit the SAP Help Portal
90
11/15/2023
To display Customizing
objects, gCTS recalculates the
object information for each
commit.
Disabled
gCTS calculates ABAP
gCTS calculates ABAP
gCTS doesn't calculate any
workbench and Customizing
workbench objects only, and
objects and doesn't generate
objects, and doesn't generate
doesn't generate an index.
an index. The object header
an index. The object header
displays the number of all
objects, and all objects are
displayed on the Objects tab.
To display any objects, gCTS
recalculates the object
information when the
repository is accessed.
The object header displays
the number of workbench
objects, and only workbench
displays N/A as the object
count, and no objects are
displayed on the Objects tab.
objects are displayed on the
Objects tab.
To display the workbench
objects, gCTS recalculates the
object information when the
repository is accessed.
Disable Automatic Pull and Push
By default, when you release a transport request or a task that uses a gCTS-speci c transport layer, or when you use the
manual push function in the gCTS app, gCTS automatically pulls the latest changes from the remote Git repository from the
branch that is currently active in the system (without importing them in the ABAP system), creates a new local commit, and
pushes the commit to the remote repository.
Context
The default pull is required so that gCTS always has the current state of the remote repository in the local repository. The
changes of the new commit can then be pushed to the remote repository. This default behavior works well in a scenario where
one or more developers work in the same branch in the same ABAP system and don’t make changes in the remote repository.
However, if you work in a setup where it’s possible that changes are made to the same les in the same lines, con icts can occur.
To make sure that you get the chance to resolve the con icts, you must disable this automatic pull and push behavior by setting
speci c repository con guration parameters.
Procedure
1. In the gCTS app, select the repository for which you want to disable the automatic pull and push actions.
2. In this repository, go to the Con guration tab.
3. Choose Create.
4. Select the VCS_AUTOMATIC_PULL parameter from the dropdown list.
5. To disable an automatic pull from the remote repository when a new commit is created in the local repository, deselect
the checkbox.
6. Choose Save.
The parameter is added to the list with the value false .
7. Select the VCS_AUTOMATIC_PUSH parameter from the dropdown list.
8. To disable an automatic push to the remote repository when a new commit is created in the local repository, deselect the
checkbox.
9. Choose Save.
This is custom documentation. For more information, please visit the SAP Help Portal
91
11/15/2023
The parameter is added to the list with the value false .
Results
If both parameters have the value false , gCTS doesn’t automatically perform a pull before the commit is created and
automatically do a push to the remote repository after the commit is created. After releasing a transport request or task, the
objects that are part of the transport request are committed to the local repository and are displayed on the Objects tab. For
more information, see Use the Objects Tab of a Repository.
Related Information
Resolve Con icts
Con guration Parameters for Repositories
Use the Activities Tab of a Repository
The Activities tab contains a history of all activities that were performed in the local repository in reverse chronological order.
Context
All activities that have an impact on the local repository are tracked.
 Example
If, for example, a commit was pulled, it’s important to know that the repository moved from commit a21fa1 to commit
ef2a901 and that change request GITK... was used to import the object differences.
Procedure
1. In the gCTS app, in the Repository view, choose the Activities tab.
For each activity, the following information is displayed:
Column
More Information
From Commit and To
Information about the commits that were involved in the activity.
Commit
From Commit: Commit that was active before the activity was run.
To Commit: Commit that was active after the activity was run.
Type
The following activity types exist:
Switch Branch: Switch to a different repository branch with import to the local ABAP system
Clone: Initial clone of the repository
Commit: Commit to the local repository
Dependency: Con guration of a dependent repository
Deploy: Manual deployment (import) of objects to the local ABAP system
Merge: Merge activity
Prerequisite: Con guration of a prerequisite software component
Pull: Pull of a commit to the local repository with import to the local ABAP system
Branch
Branch in which the activity took place.
This is custom documentation. For more information, please visit the SAP Help Portal
92
11/15/2023
Column
More Information
Request
Change request or task that was used for the activity, displayed as a link.
This can be one of the following:
Change request or task released in the ABAP system
Change request generated by gCTS. It consists of the repository´s vSID and a generated hash
value.
If errors have occurred for the activity, the log of the request can contain more information about the
cause of the error. To open the log, select the link of the request.
Status
Aggregated export or import status of the request derived from the transport log.
Possible status values:
(Request was imported/exported)
(Warnings occurred during the import/export of request)
(Errors occurred during the import/export of request)
 Note
This status does not take into account the value of the VCS_IMPORT_ERROR_LEVEL parameter
that you can set to de ne the error level. For more information, see VCS_IMPORT_ERROR_LEVEL.
Called By
Name of the ABAP user who triggered the activity
Date
Date and the time when the activity was run
2. You can perform the following tasks:
Filter the list of activities by entering any character string in the Search eld and choosing
(Search).
Go to the commits in the remote repository on the Git server.
Open the log of the request by selecting the link of the request.
For activities that are displayed here and that are logged on the Log tab, an arrow ( ) is displayed at the end of
the row. To open the corresponding process on the Log tab, click anywhere in the row.
Related Information
Use the Log Tab of a Repository
Monitoring Transports
Use the Objects Tab of a Repository
The Objects tab contains an overview of the ABAP objects in the active branch of your local repository.
Prerequisites
If you want to display con icting les, you need to have disabled the default automatic pull and push behavior of gCTS.
For more information, see Disable Automatic Pull and Push.
Context
This is custom documentation. For more information, please visit the SAP Help Portal
93
11/15/2023
If you haven't set the parameters to disable the automatic pull and push behavior of gCTS, and you haven't manually pushed
objects yet, the objects in your local repository correspond to the objects of the current commit of the active branch in your
remote repository.
You can use the Objects tab to view the objects in the local repository, and run additional tasks.
 Note
Only ABAP objects are displayed on the Objects tab. Non-ABAP objects, such as the initial README le, or the gCTS
properties le aren't displayed.
Procedure
1. In the gCTS app, in the Repository view, choose the Objects tab.
2. This tab consists of the following sections where you can run tasks:
Section
Description
Available Actions
Current Objects
Displays the objects in your
Expand the object types to display the objects of this type. Expand
local repository, organized
any object to display the les that belong to the object.
by object type. An object
can consist of more than one
le.
Deploy
Use this function to deploy (import) either a speci c commit or the
last repository action to the local ABAP system.
For more information, see Manually Deploy Objects.
Push Objects
Use this function to manually add ABAP objects to a Git repository
that aren't part of the standard development work ow.
For more information, see Manually Push Objects.
Con icting Files
If you've disabled automatic
Click on the le name link to navigate to the con ict resolution editor.
pull and push, the les of
For more information, see Use the Con ict Resolution Editor.
the objects are displayed for
each con ict found.
All con icting les are also
displayed in the Tracked
Files section.
Local Files
(More) and Add to Index in the line of the le.
Use this function after you've resolved the con icts of this le to
indicate that the le is in a status that you want to commit and push.
As a result, the le is available for a commit to the local repository
and disappears from the list of con icting les.
Displays new or changed les in the ABAP system that aren't yet pushed to the remote repository.
Tracked
Displays the les that have
Files
already existed in the
remote repository and in the
local repository and were
now changed in the ABAP
system, but aren't yet
committed to the local
repository.
All les of the Con icting
Commit
Use this function to bundle all les that are displayed in the Tracked
Files section in a commit to the local repository. To do this, choose
Commit.
For more information, see Manually Commit Files.
Push (<number of commits that are available for a push to the
remote repository>)
Files section are also
Use this function to push the commits that are available for a push to
displayed here.
the remote repository on the Git server.
For more information, see Manually Push Local Commits.
This is custom documentation. For more information, please visit the SAP Help Portal
94
11/15/2023
Section
Description
Untracked
Displays the les that are
Files
new in the ABAP system and
that aren't committed to the
local repository.
Available Actions
(More) and Add to Index in the line of the le.
You can use this function to indicate that the le is now in a state that
you want to commit and push.
After using this function, the le is added to the list of Tracked Files.
Manually Deploy Objects
By manually deploying objects, you can import a speci c scope of objects in the local ABAP system.
Manually Push Objects
You can use this function to quickly transfer objects to the remote repository without interrupting the development
process.
Resolve Con icts
Con icts occur when two or more developers make different changes to the same line of the same le, or one developer
deletes a le, which another developer changed.
Use the Con ict Resolution Editor
gCTS offers a con ict resolution editor that allows you to view differences in various versions of the same le, and then
resolve those con icts.
Manually Commit Files
You can use this function to commit to the local repository all les that are displayed in the Tracked Files section of the
Objects tab.
Manually Push Local Commits
You can use this function to push all local commits to the remote repository.
Manually Deploy Objects
By manually deploying objects, you can import a speci c scope of objects in the local ABAP system.
Prerequisites
You have sufficient authorizations to import objects in the ABAP system.
Context
You can choose to import all objects that existed in the local repository at the point in time when the current commit was
created, or import the objects that were changed by the last action that was run in the repository.
This function can be useful in the following situations:
To import client-speci c Customizing objects in more than one client:
By default, gCTS can't import Customizing objects in multiple clients at once. You can use this function to import
Customizing data into more than one client.
For more information, see About Using gCTS for Customizing Data.
You want to reimport the result of a con ict resolution, and you haven´t used the option to reimport committed les
after con ict resolution:
For example, you've resolved a con ict and you don't want to import the result of the con ict resolution in the local ABAP
system immediately after committing the resolved les. However, an object was already locked in a change request at
This is custom documentation. For more information, please visit the SAP Help Portal
95
11/15/2023
the time of the import, so that the reimport would overwrite the locked version. Therefore, you want to import the result
of the con ict resolution later.
In error situations:
For example, you've pulled a commit from the remote repository, but the import failed. You can use this function to
repeat the import.
For object types that require a redeployment:
Some object types must be imported twice.
Procedure
1. In the gCTS app, in your repository, choose the Objects tab.
2. In the Current Objects section, choose Deploy.
3. In the Deploy Objects dialog box, select the deploy scope.
You have the following options:
Current Commit
Imports the complete list of objects that existed in the local repository at the point in time when the commit was
created. Note that this deploy scope doesn't only comprise the changed objects of the commit itself. Therefore,
the import can take some time.
You can check the current commit on the Commits tab.
Last Repository Action
Use this scope, for example, to import merged les after you've resolved a con ict and you've committed the les
without reimporting the objects.
The deploy scope only deploys the object difference between the From Commit and the To Commit of the action.
On the Activities tab, you can check which repository action was last executed.
4. Choose Deploy.
Before importing objects, gCTS checks whether any of the les that are to be imported during the action refers to
objects that are locked in an open change request. If objects to be imported are currently locked, they're displayed on a
dialog box. With the help of the list of locked objects, you can evaluate the impact of the import. An import will overwrite
locked versions in the ABAP system. It's a sensitive action that can result in data loss if objects are overwritten that
other users are currently working on.
5. If the Compare Object Differences dialog box is displayed and you want to proceed, con rm the dialog box.
Results
The objects of the current commit or the last repository action are imported in the local ABAP system.
A new Deploy action is displayed on the Activities tab. You can check the log of the generated request that's related to
this activity.
Manually Push Objects
You can use this function to quickly transfer objects to the remote repository without interrupting the development process.
This is custom documentation. For more information, please visit the SAP Help Portal
96
11/15/2023
Prerequisites
You have set credentials for your user. For more information, see Set User-Speci c Authentication.
Context
Sometimes manually pushing objects to the remote repository has advantages over using the default process, for example to
onboard an ABAP package to gCTS, or to push only parts of your developments without releasing a change request or a task.
The default process for pushing objects is to change objects in the ABAP system, record the changes in a request, and release
the request or task, when the changes are completed. Afterwards, the changed objects of the request or task are pushed to the
remote repository.
You can use the manual push function to manually transfer speci c objects to the remote repository, without interrupting the
development process. You can manually push both ABAP Repository objects and Customizing objects. For objects of the type
TABL (table de nition), you can select individual table entries (TABU) or all table entries for the push.
 Note
To enable a commit and push when a task is released, you must implement the CHECK_BEFORE_RELEASE method of the
CTS_REQUEST_CHECK Business Add-In (BAdI). For more information, see the blog in SAP Community: Create a commit in
Git when an ABAP task is released
.
You can use this function for the following scenarios:
To quickly test speci c changes in a test system.
To provide a new version of some objects to a development branch for your colleagues.
To onboard an existing ABAP project (for example, a package) with gCTS.
To push the initial state of the Customizing data that you want to have in your system.
To do this, you can manually push the content of all change requests with Customizing data to the remote repository.
Note that the manual push function only works for released change requests and tasks. In addition, if you don't use the
gCTS registry for Customizing requests, the request must have the vSID of the repository assigned as a target system.
Procedure
1. In the gCTS app, in your repository, choose the Objects tab.
2. In the Current Objects section, choose Push Objects.
3. In the Push Objects dialog box, in the input eld, enter any object name, package name, released change request, or task
of a released change request that contains objects that you want to push.
a. Start typing the name of the object, and then select the objects from the list.
 Note
To push all objects of a package, enter the package name and select the entry with the gCTS-speci c object
type FULL_PACKAGE. This is useful, for example, if you want to transfer an existing ABAP project to gCTS.
To push all objects of a released change request or a task, the gCTS-speci c object type is TRANSPORT.
4. Optional: For objects of type TABL, you can choose to push only individual table entries by choosing the
primary keys of table) icon.
(Display
The primary keys of the table are displayed. You have the following options:
This is custom documentation. For more information, please visit the SAP Help Portal
97
11/15/2023
You can enter single values in the primary keys elds to push only the table entries that you entered.
You can enter an asterisk (*) to push all table entries.
To return to the Push Objects dialog box, choose the back arrow ( ). You see that the object type has changed to TABU
(table entries).
5. Enter all the objects that you want to push, one after another. They’re put on the list in the dialog box.
6. Optional: To delete an object, select it and choose
(Delete).
7. Once you’ve entered all the objects that you want to push, enter a commit message in the corresponding eld.
If you don´t enter a commit message, the default commit message Direct push of x objects is generated.
8. By default, the Synchronous Push checkbox is selected.
 Recommendation
Leave this option selected.
Use the asynchronous push only to push a large set of objects. In this case, the gCTS observer job is used in the ABAP
system to run an asynchronous push process. This requires the user who scheduled the observer job to be a
collaborator in the remote repository.
9. Choose Push.
 Note
You don’t need to select the objects that you want to push. All objects displayed in the list are pushed.
10. Con rm that you want to push the objects.
Results
The push process is as follows:
1. By default, gCTS creates a change request of type Transport of copies, adds the objects that you want to push to the
object list, and automatically releases this request.
gCTS-speci c request attributes are assigned to the request. If you don't use the gCTS registry, one of the
attributes is SAP_SCTS_AVCS_TARGET. The value of this attribute is the repository ID of the repository to which
the objects were pushed.
Because the request is of type Transport of copies, no versions are created in the version database for these
objects.
2. After the request is released, the objects are rst committed to the local repository.
If you’ve selected a request, a task, or an object that comprises more than one object (for example, an ABAP
package), all objects that are part of the request, task, or package are committed to the local repository.
If the Synchronous Push checkbox is selected, and the automatic pull and push behavior isn't disabled in your
system, the objects are also directly pushed to the remote repository.
In this case, you can check the result of the push in the following places:
On the Objects tab:
The pushed objects are displayed in the Current Objects section.
On the Commits tab:
Because the push is shown as a separate activity, you nd the commit on the Commits tab.
This is custom documentation. For more information, please visit the SAP Help Portal
98
11/15/2023
The commit message contains the ID of the generated transport of copies and the commit message that
you entered. If you haven't entered a commit message, the generated text: Direct push of x objects is
displayed.
On the Activities tab:
The manual push is displayed as a separate activity. The request number that was created as a Transport
of Copies to perform the push is displayed in the Request column. To display the log of the request, select
the link.
In the remote repository:
On the Commits tab of your repository, choose the link to the commit in the remote repository. Check that
the objects are available in the repository.
If the default automatic pull and push process is disabled in your repository and if you've left the Synchronous
Push checkbox selected, the objects are only committed to the local repository without being pushed to the
remote repository. In this case, a Push button appears on the Objects tab that allows you to manually push the
local commits. For more information, see Disable Automatic Pull and Push and Manually Push Local Commits.
Resolve Con icts
Con icts occur when two or more developers make different changes to the same line of the same le, or one developer deletes
a le, which another developer changed.
Prerequisites
You have enabled con ict resolution. To do this, you've disabled gCTS’s automatic pull and push behavior. For more
information, see Disable Automatic Pull and Push.
A con ict le is displayed on the Objects tab under Con icting Files.
Context
Con icts can arise in many situations in Git. For example:
One branch is merged into another, and in both branches, changes were made to the same lines in the same les.
Changes are made to the same lines in the same les, both locally and in your remote Git repository.
For example, there are changes in the remote version of an object that you don’t want to overwrite by your new commit.
If gCTS’s automatic pull and push behavior is disabled, gCTS detects con icts in the affected les and displays them on the
Objects tab. You use the con ict resolution editor to resolve the con icts. Afterwards, you manually commit the changed les to
the local repository, and push them to the remote repository.
Procedure
1. On the Objects tab, under Con icting Files, select the link to the le where you want to resolve con icts.
The con ict resolution editor opens.
2. In the Merged Version panel, perform your con ict resolution.
To do this, you have the following options as described in the Use the Con ict Resolution Editor topic in the Con ict
Resolution Options table.
This is custom documentation. For more information, please visit the SAP Help Portal
99
11/15/2023
3. Once you’ve resolved all the con icts and you have a version of the le that you want to keep, you have the following
options as described in the Use the Con ict Resolution Editor topic in the Finish Con ict Resolution table.
4. To close the con ict resolution editor, choose Cancel.
5. Repeat the previous steps for all les that are displayed in the Con icting Files section.
If you've marked the con icts as resolved, the le disappears from the list of con icting les. It’s now displayed in the
Local Files section under Tracked Files.
If you've saved the con ict resolution, the le is still available under Con icting Files. If you still need to work on the
con ict resolution, return to the con ict resolution editor, and continue with step 3.
6. If you've completed the con ict resolution and you now want to commit and push the le, add it to the index of the local
repository.
Choose
(More) and Add to Index in the line of the le.
 Caution
Make sure that you’ve successfully removed the con icts. After you’ve added the le to the index of the local
repository, you can’t modify the con ict resolution for this le. The con ict resolution editor is no longer available. To
discard the local changes introduced with the con ict resolution, you can reset the local repository. For more
information, see Reset Local Repository.
 Note
gCTS doesn’t perform checks on the source code. However, we recommend that you have a CI process in place that
triggers a pipeline to test your changes whenever objects are pushed. For more information, see Integration of gCTS
in CI Pipelines.
7. To commit the les to the local repository, in the Local Files section, choose Commit.
Enter a commit message, and decide whether you want to reimport the committed les to the local ABAP system.
For more information, see Manually Commit Files.
 Caution
The system allows you to commit con icting les without resolving the con icts beforehand. Make sure that you
resolve all con icts before committing les that have con icts.
A Push button appears.
 Note
If the Push button isn’t active, this means that a new commit exists in the remote repository that wasn’t yet pulled to
the local repository. First pull this commit to your local repository. To do this, choose Update to Latest Commit on the
Commits tab.
8. To push all local commits to the remote repository, choose Push, and then con rm this in the subsequent dialog box.
For more information, see Manually Push Local Commits.
Results
You've resolved a con ict and pushed the result of the con ict resolution to the remote repository. If you've selected the option
to reimport the committed les, the result of the con ict resolution is reimported in the local ABAP system.
Related Information
Blog post: Con ict Resolution with gCTS
This is custom documentation. For more information, please visit the SAP Help Portal
100
11/15/2023
Use the Con ict Resolution Editor
gCTS offers a con ict resolution editor that allows you to view differences in various versions of the same le, and then resolve
those con icts.
Prerequisites
You've disabled gCTS’s automatic pull and push behavior. For more information, see Disable Automatic Pull and Push.
Con icting les are displayed on the Objects tab.
You have experience with merging in Git.
Context
The con ict resolution editor is opened when you select the link of a con icting le.
It displays three versions of a con icting le in three panels:
Local Version
This panel displays the version of the object as it's available in the database of the ABAP system. This version of the le
can contain changes to the object that were introduced after the object was committed to the local repository. This
means that an open change request can still exist in your ABAP system and contain this object in the displayed version.
The content of the le in the Local Version can be different from the version that was committed to the local repository.
Make sure you’re aware that there can be a difference between the Local Version and the version that was committed
to the local repository.
Check the content in the Local Version panel, to verify whether it's necessary to integrate these changes into the con ict
resolution too.
You can’t edit the content in this panel.
Merged Version
This panel displays a merged version of the version of the le that was committed to the local repository and the remote
version of it. That is, the panel displays the merged version between the local commit and the remote commit. The
merged version contains con ict markers indicating the location of the con ict in this le. In the con ict markers, the
content of the local and the remote le is displayed.
The format is as follows: <<<<<<<HEAD <content of local file ========= content of remote file>
>>>>>>> branch <branch name> of <URL of repository>.
In the Merged Version panel, you perform your con ict resolution.
You can edit the content in this panel.
 Note
If you've changed the object after the object was committed to the local repository, the content in the Merged
Version panel doesn’t show the merged version between the Local Version and the Remote Version panel. Instead, it
shows the merged version between the version that was committed to the local repository and the remote version.
Remote Version
This panel displays the remote version of the le. This is the version that currently exists in the remote repository on the
Git server for the current commit of the local repository in the active branch.
This is custom documentation. For more information, please visit the SAP Help Portal
101
11/15/2023
You can’t manually edit the content in this panel, but you can select to display the version of a speci c branch and
commit.
 Note
For le types that aren’t directly related to the object, for example, for nametab, or properties les, the three-version
comparison isn’t available. These are displayed in the Merged Version panel only.
For repositories on Git servers other than GitHub, it's possible that gCTS can’t retrieve the local or the remote versions of a
le. In this case, a message is displayed. For an overview of known restrictions for Git servers other than GitHub, see SAP
Note 2821718
.
Procedure
1. In the Objects tab, under Con icting Files, select the link to the le for which you want to open the con ict resolution
editor.
2. In the con ict resolution editor, you can see how many con icts there are in your le. You have the following options:
Conflict Resolution Options
Function
Description
Con ict Files
If multiple con icting les exist, use this function to open another le.
Accept Local
The version of the le that is displayed in the Local Version panel is copied to the Merged
Version panel.
Accept Remote
The version of the le that is displayed in the Remote Version panel is copied to the Merged
Version panel.
(Scroll individually) /
(Scroll synchronously)
(Settings)
Enables/disables individual or synchronous scrolling in the three panels.
By default, three panels are displayed. You can choose to hide the panel of either the local or
remote version, or both.
(Show version in fullscreen mode)
Opens the le version in full-screen mode. Only the merged version can be edited.
Available in the Merged
Goes to the next/previous con ict.
Version panel: (navigation-
down-arrow) /
up-arrow)
(navigation-
Double-click on a con ict
Opens a dialog box with the following con ict resolution options:
header line (<<<<<<< HEAD)
Accept Current Changes: The version of the le that was committed to the local
repository is retained in the Merged Version panel.
Accept Incoming Changes: The version of the le that is displayed in the Remote
Version panel is retained in the Merged Version panel.
Accept Both Changes: Both the version that was committed to the local repository and
the Remote Version are retained in the Merged Version panel.
Cancel: Closes the dialog box without any changes.
Available in the Remote
If the repository has multiple branches, this option allows you to select another branch from the
Version panel: Branch
list.
dropdown box
This is custom documentation. For more information, please visit the SAP Help Portal
102
11/15/2023
Function
Description
Available in the Remote
If you've selected a branch, this option allows you to select a remote commit.
Version panel: Commit
dropdown box
(Show con icts)
Opens a dialog box that indicates in which lines the con icts occur.
3. After you’ve worked on resolving the con icts, you have the following options:
Finish Conflict Resolution
Function
Description
Save
Saves the le in the current state of con ict resolution.
This is useful, if you’ve started resolving a con ict, and you want to return to the con ict resolution at
later.
Mark As Resolved
If you’ve resolved all con icts, use this function to add the le to the index of the local repository.
 Note
You can only use this function after you’ve resolved all con icts.
As a result, you’re asked to con rm that you want to save the le and add it to the index of the local
repository. As such, you indicate that the le is now in a state that you want to commit.
 Caution
Make sure that you’ve successfully removed the con icts. After you’ve added the le to the index of
the local repository, you can’t modify the con ict resolution for this le. The con ict resolution editor
is no longer available. If you need to redo the con ict resolution, you can reset the repository. For
more information, see Reset Local Repository.
 Note
gCTS doesn’t perform checks on the source code. However, we recommend that you have a CI
process in place that triggers a pipeline to test your changes whenever objects are pushed. For more
information, see Integration of gCTS in CI Pipelines.
Cancel
Closes the con ict resolution editor and returns to the Objects tab.
Manually Commit Files
You can use this function to commit to the local repository all les that are displayed in the Tracked Files section of the Objects
tab.
Prerequisites
There are les available for a commit to the local repository. The Commit button is displayed only when there are les to
commit. This can occur in the following situations:
You've disabled the automatic pull and push behavior of gCTS.
You've encountered a con ict, resolved it, and added the le to the index of the local repository.
Context
This is custom documentation. For more information, please visit the SAP Help Portal
103
11/15/2023
Note that this function commits all les available in the Tracked Files section of the Objects tab to the local repository on the
ABAP system. You can’t select individual les and commit only the selected les. Filtering the list using the Search function
doesn’t limit the number of les that are committed either.
On the next dialog box, you can select whether you want to reimport the les to the local ABAP system after committing them.
This function is useful, for example, if you've resolved con icts, and the version of the resolved les differ from the versions in
the local ABAP system. Committing and pushing the les to the remote repository doesn't automatically change the versions in
the local development system. If you want to have the resolved versions also in the development system, select the
corresponding checkbox.
Before importing objects, gCTS checks whether any of the les that are to be imported during the action refers to objects that
are locked in an open change request. If objects to be imported are currently locked, they're displayed on a dialog box. With the
help of the list of locked objects, you can evaluate the impact of the import. An import will overwrite locked versions in the ABAP
system. It's a sensitive action that can result in data loss if objects are overwritten that other users are currently working on.
If you choose not to import a le immediately after committing it, you can do it later using the Deploy function. For more
information, see Manually Deploy Objects.
 Caution
If you commit les after you’ve resolved a con ict, make sure that all con icts in the les listed under Con icting Files are
resolved.
Procedure
1. In the gCTS app, in your repository, choose the Objects tab.
2. In the Tracked Files section, choose Commit.
3. In the subsequent dialog, enter a commit message, and choose Commit.
A dialog box opens that allows you to select whether you want to import the les to the local ABAP system. By default,
the Reimport committed les checkbox isn't selected.
4. Analyze for your situation for whether you want to reimport the committed les.
If the les to be committed relate to objects that are currently locked in the system, the objects are also displayed on
the dialog box together with the owner of the transport.
5. If you want to reimport the committed les, select the checkbox.
6. Choose Commit.
Results
All les that were displayed under Tracked Files are committed to the local repository (on the le system). A toast
message con rms this.
All committed les are combined in a commit. They disappear from the list of Tracked Files because they’re now
committed to the local repository.
To display the new local commit, go to the Commits tab, and choose the local branch from the dropdown box. Note,
however, that the link to the commit doesn't work as long as the commit wasn't pushed to the remote repository.
Check on the Log tab that a COMMIT action has been logged with a green status.
If you've selected the Reimport committed les checkbox, the commit was used to redeploy the objects on the ABAP
system. A toast message con rms the import. You can check on the Log tab that a DEPLOY process has been logged
with a green status. In addition, on the Activities tab, the log of the generated change request for the Deploy activity
also contains information about the import.
This is custom documentation. For more information, please visit the SAP Help Portal
104
11/15/2023
The Commit button disappears, and a Push button appears.
Next Steps
Manually Push Local Commits
Manually Push Local Commits
You can use this function to push all local commits to the remote repository.
Prerequisites
There are local commits available for a push to the remote repository. The Push button is displayed only when there are
commits that can be pushed. This can occur in the following situations:
You've disabled the automatic pull and push behavior of gCTS.
You've manually committed les to the local repository. See Manually Commit Files.
You've released a transport in the development system, which resulted in a local commit. The automatic push to the
remote repository failed, for example because of insufficient authorization.
Context
After you’ve committed les to the local repository, they’re available for the push to the remote repository. The Push button
contains the number of commits that will be pushed - in brackets (), for example, (2). This is the number of commits by which
the local repository is ahead of the remote repository.
 Note
To check which local commits are currently available for a push to the remote repository, on the Commits tab, select the
active local branch from the dropdown box.
Procedure
1. In the gCTS app, in your repository, go to the Objects tab.
2. In the Tracked Files section, choose Push.
3. Con rm that you want to push the objects.
Results
All local commits are pushed to the remote repository. A toast message indicates this.
To check this, you have the following options:
On the Commits tab, verify that a new commit has been created. From there, you can go to the remote
repository.
On the Log tab, check that the PUSH action has been logged with a green status.
The Push button is no longer available under Tracked Files.
This is custom documentation. For more information, please visit the SAP Help Portal
105
11/15/2023
Related Information
Use the Log Tab of a Repository
Use the Branches Tab of a Repository
The Branches tab provides an overview of the branches of a repository. You can create new branches, compare the object
differences between a selected branch and the active branch, switch to selected branches, merge branches, and delete existing
branches.
Prerequisites
You have a good knowledge about branching in Git. Knowing how to merge branches is especially important. The gCTS
app doesn’t issue any warnings, for example, if a branch that you want to merge, isn’t on the latest commit.
For more information, refer to the relevant sections in References to Git Documentation.
Context
To support different release versions of the software of one repository, you can create additional branches in the repository. This
allows you to perform maintenance for older release versions, and to reorganize the repository, such as split it or move a
package from one repository to another. Branching also lets you change the repository during its lifecycle. In the development
phase, you work in one repository branch, for example, the feature branch. After the initial release of the software, you can
create a release branch for the delivered state, and use the feature branch for ongoing development.
The branch that is active in the local repository is displayed in the Branch eld in the header of the Repository view. The
commits of the active branch are displayed in the commits list on the Commits tab. From the branches dropdown list, you can
select any local or remote branch that exists in this repository and display the respective commits of the selected branch
version.
The Branches tab of a repository contains a list of branches that exist in this repository. For each branch, information is
displayed about whether the branch is available in the remote repository, or in the local repository, or both. The branch that
you’re currently working on is set to active .
After the repository is created on the ABAP system, it contains a default branch. After the repository is cloned to the ABAP
system, the default branch of the remote repository is set to active .
Procedure
1. In the gCTS app, in the Repository view, choose the Branches tab.
2. On the Branches tab, you can do various tasks.
Create Branches in a Repository
To support different release versions of the software of one repository, you can create additional branches in the
repository.
Compare Branches of a Repository
To nd out the object differences between a selected branch and the active branch, you can use this function.
Switch the Branch of a Repository
By switching the branch of a repository on the ABAP system, the source code differences between the latest commit of
the selected branch and the branch that was previously active are imported in the system.
Merge Branches of a Repository
This is custom documentation. For more information, please visit the SAP Help Portal
106
11/15/2023
By merging a branch into another branch, the developments of the two branches are combined into one.
Delete Branches of a Repository
If you no longer need a branch, for example after merging a correction branch into a release branch, you can delete it.
Create Branches in a Repository
To support different release versions of the software of one repository, you can create additional branches in the repository.
Prerequisites
You're in the gCTS app, on the Branches tab of a repository.
Procedure
1. To create a new branch based on the currently active branch in the system, choose Create.
2. In the dialog box, enter the Name of the new branch.
3. Select the Type of the new branch:
Remote: Creates the branch on the ABAP system and transfers it immediately to the remote Git repository.
This is the default option.
Local: Creates the branch only on the ABAP system.
4. Choose Create.
Results
A new branch is created and automatically set as the active branch. If you've created a remote branch, it's also available in the
remote repository.
Creating a branch is logged as a CREATE_BRANCH process. You can nd details on the Log tab.
Compare Branches of a Repository
To nd out the object differences between a selected branch and the active branch, you can use this function.
Prerequisites
You're in the gCTS app, on the Branches tab of a repository.
Context
 Recommendation
Use this function before you merge a branch into another one.
Procedure
In the line of the branch that you want to compare with the active branch, choose
(Compare selected branch with active
branch.).
This is custom documentation. For more information, please visit the SAP Help Portal
107
11/15/2023
Results
If the branches exist in both the remote and the local repository, the system compares the objects in the remote repository. If a
branch exists in the local repository only, the objects in the local repository are used for the comparison.
As a result, the system displays the objects that differ between the two branches and the type of the change (object is created,
deleted, or modi ed).
 Restriction
This function does not show detailed changes in objects. For in-depth comparison, use the speci c branch comparison
function offered by your Git provider.
Switch the Branch of a Repository
By switching the branch of a repository on the ABAP system, the source code differences between the latest commit of the
selected branch and the branch that was previously active are imported in the system.
Prerequisites
You're in the gCTS app, on the Branches tab of a repository.
Procedure
1. Optional: To nd out which objects are affected when switching the branch, use the
active branch.) function.
(Compare selected branch with
2. To switch the branch, choose (Branch of local repository will be switched to selected branch (object difference will be
imported depending on con guration).) in the row of the branch that you want to switch to.
The following con guration parameters can in uence this action:
VCS_NO_IMPORT
VCS_BUFFER_ONLY
For more information, see Con guration Parameters for Repositories.
 Note
You can choose to run the task as a background job. To do this, select the dropdown arrow ( ) next to the
(Branch
of local repository will be switched to selected branch (object difference will be imported depending on
con guration).) icon and choose
Run in Background. For more information, see Schedule Background Jobs for gCTS
Activities.
Before importing objects, gCTS checks whether any of the les that are to be imported during the action refers to
objects that are locked in an open change request. If objects to be imported are currently locked, they're displayed on a
dialog box. With the help of the list of locked objects, you can evaluate the impact of the import. An import will overwrite
locked versions in the ABAP system. It's a sensitive action that can result in data loss if objects are overwritten that
other users are currently working on.
3. If the Compare Object Differences dialog box is displayed and you want to proceed, con rm the dialog box.
4. Con rm that you want to switch to the selected branch.
Results
This is custom documentation. For more information, please visit the SAP Help Portal
108
11/15/2023
When the branch was switched, this has the following results:
The switched branch is set as the Active branch.
The latest commit of the branch is now the current commit.
If not prevented by parameters or locked objects, the changed objects were imported in the ABAP system.
Switching the branch is logged in the following places:
As a Switch Branch activity on the Activities tab.
If objects were imported by the Switch Branch activity, you can nd a log of the change request that was created
for the import.
As a SWITCH_BRANCH process on the Log tab.
Merge Branches of a Repository
By merging a branch into another branch, the developments of the two branches are combined into one.
Prerequisites
You're in the gCTS app, on the Branches tab of a repository.
Procedure
1. Optional: If you want to see whether there will be any con icts as a result of the merge action before actually running it,
use the (Compare selected branch with active branch.) function before running the merge.
Con icts occur if the same objects were changed both in the local repository of the selected branch and in the active
branch of the repository into which you want to merge the selected branch.
2. To merge a branch into the active branch, choose (Selected branch will be merged into active branch of local
repository) in the row of the branch that you want to merge into the active one.
3. If necessary, select a Merge Strategy and a Fast Forward Option.
These options allow you to customize the merge process.
The following merge strategies are available:
Recursive (Default)
Resolve
Ours
Theirs
The following fast forward options are available:
Fast Forward (Default)
Fast Forward Only
No Fast Forward
For more information about merge strategies and merge options in Git, refer to Git merging.
 Recommendation
In general, we recommend that you leave the default options selected.
This is custom documentation. For more information, please visit the SAP Help Portal
109
11/15/2023
4. Choose Merge Branch.
5. Con rm the dialog box.
If no con icts occur, the selected branch is immediately merged into the active branch. The affected commits are
not pushed to the remote repository.
If con icts occur, and gCTS can automatically resolve the con ict, a merge commit is created. The affected
commits and the merge commit are not pushed to the remote repository.
If con icts occur, and gCTS cannot automatically resolve the con ict, an error message is displayed notifying you
about the con ict.
6. Optional: On the Objects tab, resolve any con icts, if necessary.
For more information, see Resolve Con icts.
7. To push the commits affected by the merge activity to the remote repository, choose Push.
Results
Merging branches has the following results:
On the Commits tab, the merged commits are displayed as part of the active branch, including the merge commit. The
merge commit has the generated text: Merge commit '<Commit ID of the latest commit in the branch that you want to
merge into the active one>' into <active branch>'.
Merging a branch is logged in the following places:
As a Merge activity on the Activities tab. The name of the active branch is displayed in the Branch column.
As a MERGE process on the Log tab.
Delete Branches of a Repository
If you no longer need a branch, for example after merging a correction branch into a release branch, you can delete it.
Prerequisites
You're in the gCTS app, on the Branches tab of a repository.
Procedure
In the line of the branch that you want to delete, choose
(Selected branch will be deleted.).
 Note
Active branches can't be deleted.
Results
The branch is deleted from the local repository.
If the deleted branch also existed in the remote repository, it’s deleted there as well.
Deleting a branch is logged as a DELETE_BRANCH process on the Log tab.
This is custom documentation. For more information, please visit the SAP Help Portal
110
11/15/2023
Use the Log Tab of a Repository
gCTS logs all actions that are performed for a speci c repository.
Context
Use the Log tab to view logs of actions that have been done on a repository.
Procedure
1. In the gCTS app, in the Repository view, choose the Log tab.
A list of log IDs, each ID corresponding to a process that was performed in this repository, are displayed in reverse
chronological order.
For each process, status icons are displayed. The following statuses exist:
Green
Red
(Action was completed)
(Errors occurred during the action)
The following statuses exist for scheduled actions:
Blue
(Action is scheduled)
Blue
(Scheduled action was run)
Green
(Scheduled action was nished)
2. Click anywhere in the line of a process to go to the detail log display.
A new dialog opens that contains detailed information about the different steps of the process.
3. You can display logs of different applications:
gCTS
Logs that were raised in the gCTS app.
 Note
If the error messages displayed here don´t provide sufficient information about the cause of an error, you can
use the application log in the ABAP system to get more information. To do this, proceed as follows:
a. Start transaction SLG1.
b. As Object, enter CTS.
c. As Subobject, enter ABAPVCS.
d. To restrict the number of results, select a speci c time frame.
e. Choose Execute.
For more information, choose Analyze Logs.
Transport Tools
Log of the transport tool tp. For more information about tp logs and return codes, see How tp Works.
 Note
For more information about the cause of an error, check also the TMS Alerts in the ABAP system in
transaction STMS. Choose
Monitor
TMS Alerts
TMS Alert Viewer .
This is custom documentation. For more information, please visit the SAP Help Portal
111
11/15/2023
Git Client
Log of the Git client abap2vcs.jar
When you open this log, the application log of the Git client, the Java application abap2vcs.jar, is displayed.
Using the dropdown menu, you can display the following information:
Parameters: Parameters of the action.
Response: Response le of the Git client.
Stack Log: Errors of the response le. This section contains only data, if errors occur.
If there's an error icon for any action, open the detail display of the log. The Git client log displays a red [ERROR] line
with more information about the cause of the error.
The error message is also displayed, if you select
Response
log
message .
4. To close the log, choose Close.
Use the Registry Tab of a Repository
The Registry tab provides an overview of the objects of the current repository that have been registered in the gCTS registry.
You can also use it to register new objects in the gCTS registry.
Prerequisites
You're familiar with the concepts of the gCTS registry.
For more information, see gCTS Registry.
The gCTS registry is con gured in the ABAP system.
The Registry tab is available only if the registry is con gured. For more information, see Con gure the gCTS Registry.
You have the authorizations required to use the Registry tab.
Procedure
1. In the gCTS app, in the Repository view, go to the Registry tab.
2. On the Registry tab, you can do various tasks.
Register Git Repositories in the gCTS Registry
Before you can register ABAP objects in the gCTS registry, you must register the Git repository to which you want to
assign the objects.
Register ABAP Objects in the gCTS Registry
By registering ABAP objects in the gCTS registry, you assign them to a Git repository.
Display and Change Repository Details in the gCTS Registry
You can display and change the details of a registered repository, as well as register additional branches of the
repository.
Register Git Repositories in the gCTS Registry
This is custom documentation. For more information, please visit the SAP Help Portal
112
11/15/2023
Before you can register ABAP objects in the gCTS registry, you must register the Git repository to which you want to assign the
objects.
Procedure
1. In the gCTS app, in the Repository view, go to the Registry tab.
The rst time you open the Registry tab in the Repository view, the system tells you that the repository isn't yet
registered in the registry.
2. Choose Register Repository.
3. Select the type under which you want to register the repository.
The following types are available:
Distributed Development
This is the default type.
Code Review
Only use this type, when you don't want to import the registered objects in any other system.
4. Choose Save.
The repository is registered in the gCTS registry.
Next Steps
Register ABAP Objects in the gCTS Registry
Register ABAP Objects in the gCTS Registry
By registering ABAP objects in the gCTS registry, you assign them to a Git repository.
Prerequisites
You've registered the repository for which you want to register objects as described under Register Git Repositories in the gCTS
Registry.
Procedure
1. In the gCTS app, in the Repository view, choose the Registry tab.
2. Choose Register Object.
3. In the Register Object dialog box, enter the name of the object that you want to register.
You can enter the name of an individual object, a package, or a change request or a task.
4. If you select an object, the object type is automatically entered.
As a preparation step, you can also register an object that isn't yet created, if you plan to create it later. In this case,
make sure you enter the correct object type and the correct name that you plan to use for the object. Note that the
system doesn't check that the object type is valid.
 Note
You can nd the list of valid object types, for example, in the request editor of any change request. On the Objects
tab, in the Object Type column, choose the input help. gCTS supports all objects of the program ID: R3TR.
This is custom documentation. For more information, please visit the SAP Help Portal
113
11/15/2023
You can register all objects of a package by entering the name of the package and selecting the special object type
FULL_PACKAGE. All objects are registered that are part of the package at the time of the registration. This is useful if
you want to transfer an existing ABAP project to gCTS for example. Note that you must register additional objects of the
package individually when you create them later.
If you enter a request or a task, the corresponding gCTS-speci c object type is TRANSPORT.
5. Optional: For objects of type TABL, you can choose to register only individual table entries by choosing De ne Table
Content.
The object type changes to TABU. The primary keys of the table are displayed. You've the following options:
You can enter single values in the primary keys elds to register only the table entries that you entered.
You can enter an asterisk (*) to register all table entries.
 Caution
If you don't enter any values for individual table entries here, individual table entries (TABU) without any value will be
registered. If you want to register the table object (TABL), manually change the object type back to TABL.
6. Choose Register.
Results
If you entered an individual object, it's registered in the gCTS registry.
If you've entered an object of the type FULL_PACKAGE, all objects that are currently part of the package are registered
as individual objects. The package entry itself is registered with the object type DEVC.
If you've entered an object of type TRANSPORT, all objects that are currently part of the request or task are registered
as individual objects.
If you've registered table content, an additional icon
(Display Table Content) is displayed in the object row. To display
the table content, choose the icon.
To unregister an object, choose
(Unregister Object) in the object row.
Display and Change Repository Details in the gCTS Registry
You can display and change the details of a registered repository, as well as register additional branches of the repository.
Procedure
1. In the gCTS app, in the Repository view, choose the Registry tab.
2. Choose Registry Details.
The details of the current repository are displayed:
URL to the remote Git repository
ABAP user that registered the repository
Registration date and time
Selected type of registry entry for the repository
3. Optional: To change the type, select another type from the dropdown list next to the Type eld.
4. Optional: Register speci c branches of the repository in the gCTS registry.
This is custom documentation. For more information, please visit the SAP Help Portal
114
11/15/2023
By default, when the rst object of a repository is registered, the active branch is automatically registered. If you work
with multiple branches, you can register additional branches, if necessary. For example, you can register a new
maintenance branch after you've created it, and then continue to work in the feature branch for your ongoing
development.
Only register additional branches, if necessary.
a. To register a branch, choose Register Branch.
b. Select the branch, and save your change.
5. Optional: Display the details of a registered branch.
To do this, click anywhere in the branch row.
6. Optional: To unregister a branch from the gCTS registry, display the branch details, and choose Unregister Branch.
7. Optional: To unregister a repository from the gCTS registry, choose Unregister.
Related Information
gCTS Registry
Use the Properties Tab of a Repository
On the Properties tab of a repository, you can set dependencies and prerequisites of the repository, and change its default
layout properties.
Prerequisites
You've created and cloned a Git repository to the ABAP system. For more information, see Clone the Remote Git
Repository to the ABAP System.
Procedure
1. In the gCTS app, in the Repository view, choose the Properties tab.
2. This tab consists of sections where you can do verious tasks.
Use the Dependencies Section of the Properties Tab
The Dependencies section of the Properties tab allows you to manage dependencies of a repository.
Set Prerequisites of a Repository
You can set prerequisites for cloning a repository.
Set the Repository Layout
You can display the layout properties of a repository, and change them if necessary.
Use the Dependencies Section of the Properties Tab
The Dependencies section of the Properties tab allows you to manage dependencies of a repository.
Prerequisites
You're in the gCTS app, on the Properties tab of a repository.
This is custom documentation. For more information, please visit the SAP Help Portal
115
11/15/2023
Context
Projects that are stored in a particular repository may depend on projects in other repositories. If you want to deploy one of
your repositories to a target system (for example, the test system), it may be required that the content of another repository is
also available on the target system. Before cloning the repository to the ABAP system, the dependent repository must have
been cloned to the ABAP system. To ensure this, on the development system, you can set dependencies of your repository to
other repositories.
 Note
Currently, gCTS does not enforce dependent repositories to be cloned before cloning the current repository. Before cloning a
repository to a target system, check on the Properties tab to nd out whether the cloned repository has dependencies. If
there are dependencies, clone the dependent repositories before you clone the current one.
Procedure
1. On the Properties tab, go to the Dependencies section.
All dependencies of the current repository are displayed on a canvas. The current repository is displayed as a node, along
with the number of direct dependencies. If the current repository has a version, its current version is also displayed. If
dependencies exist, they are represented as nodes connected by lines. Dependent repositories are displayed with their
dependency status and the expected version.
The following statuses exist for dependencies:
ok
incompatible
missing
cyclic
unknown
2. In the Dependencies section, you can do various tasks:
Task
Function in
Description
the gCTS
App
Create new
Create
For more information, see Set Dependencies of a Repository.
Delete
This deletes the dependency. The dependent repository isn't deleted from the system. If you
dependencies.
Delete an
existing
don't need it for other purposes, delete it manually.
dependency.
Expand all
Deleting a dependency creates a new commit.
Expand All
dependencies of
Select a repository node to expand all dependencies (direct dependencies and subdependencies).
the selected
repository.
Refresh
dependency
data.
(Refresh) |
(Empty
Cache and
Refresh)
If you experience refresh issues after creating or deleting dependencies, use the dropdown
arrow ( ) next to the
(Refresh) icon to access the
(Empty Cache and Refresh) function.
This is custom documentation. For more information, please visit the SAP Help Portal
116
11/15/2023
Task
Function in
Description
the gCTS
App
Display the
(Legend)
The legend explains the colors used for the repository nodes on the canvas.
legend.
 Note
The legend only explains visible elements.
The following colors exist:
Blue: Current Repository
Green: Dependency is OK
Yellow: Dependency with Warning
Red: Dependency with Error
3. Using the icons next to a selected repository node, you have the following options.
Option
Description
If the current repository has dependencies that are currently not displayed, an information
(Expand/Collapse)
(Collapsed)
icon in the top left of the node indicates this. To expand the dependencies, select the repository and choose
(Expand/Collapse).
(Details)
Display dependency-relevant information about the selected repository.
(Links)
Display links to the repository.
Use the Open on Git Server link to open the remote repository.
Use the Open in gCTS App link to open the local repository in the Repository view of the gCTS app.
(Delete)
Delete a dependency from the current repository.
Set Dependencies of a Repository
You can set dependencies to other repositories that your repository depends on.
Set Dependencies of a Repository
You can set dependencies to other repositories that your repository depends on.
Prerequisites
For the code in your Git repository to work correctly, another repository must exist on the system. You want to use gCTS
to model the dependency.
You're in the gCTS app on the Properties tab of a repository.
Context
When setting dependencies, note the following points:
This is custom documentation. For more information, please visit the SAP Help Portal
117
11/15/2023
We recommend setting a dependency to a speci c version of a repository to ensure stability. In gCTS, you can use tags to
create versions. Setting a dependency to a tagged state of a repository helps ensuring stability.
For more information, see About Versions of Repositories in gCTS.
We recommend setting dependencies on development systems where the repository exists in the required version.
Avoid creating cyclic dependencies. gCTS detects and displays cyclic dependencies, but it doesn't prevent their creation.
If the repository has multiple branches, you set the dependency for the active branch of the repository.
Procedure
1. In the Dependencies section, choose Create.
2. In the dialog box, enter or select the following details:
Field
Description
Repository
Select the repository to which you want to set a dependency.
Once you've made a selection, the corresponding URL is displayed as a link.
Option
Select one of the following dependency options:
Version (default)
Branch
Commit
Version
By default, any version of the dependent repository is set as validity of the dependent repository. You can
further specify accepted versions of the dependent repository using the following operators:
Greater Than
Greater Than or Equal To
Equal To
Lower Than or Equal To
Lower Than
To specify a version, use the semantic versioning format.
 Example
1.1.0
v1.0.3
For more information, see https://semver.org/
.
If you use the Equal To operator, you can specify acceptable version ranges using x as placeholder.
 Example
1.x.x
v1.0.x
This is custom documentation. For more information, please visit the SAP Help Portal
118
11/15/2023
Field
Description
Branch
Use this option to specify a certain branch of a repository as a dependency.
You can select all branches of the dependent repository from the dropdown menu.
 Note
If you select a branch that isn't the active branch of the repository, the status of the dependency is set
as missing.
Commit
Use this option to restrict the validity of the dependent repository to a speci c commit.
You can select a branch of the dependent repository from the dropdown menu. And then enter an existing
commit.
Results
The dependent repository is displayed on the canvas in the Dependencies section.
A new commit is created with a generated text Add dependency for repository <repository name>. You can check it on
the Commits tab.
On the Activities tab, a new Dependency activity is displayed.
On the Log tab, you can check the log of the corresponding COMMIT process.
The dependencies key and value property is added to the .gcts.properties.json le in the remote repository.
 Caution
When the repository is cloned to a target system, gCTS doesn't issue any noti cation that the dependent repositories must
be imported beforehand. For more information, see Use the Dependencies Section of the Properties Tab.
Related Information
The gCTS Properties File
Set Prerequisites of a Repository
You can set prerequisites for cloning a repository.
Prerequisites
You're in the gCTS app, on the Properties tab of a repository.
Context
You can de ne that a speci c minimum software component version must be installed in the ABAP system as a prerequisite for
cloning the repository to another system.
If the repository has multiple branches, you set the prerequisite for the active branch of the repository.
This is custom documentation. For more information, please visit the SAP Help Portal
119
11/15/2023
Procedure
1. In the Prerequisites section of the Properties tab, choose Create Prerequisite.
2. In the dialog box, enter the following details:
Field
Description
Component
Software component
Example: SAP_BASIS
Release
Release of the software component
Example: 757
Support Package
Speci c Support Package of the software component release
Example: 00
Results
Adding the prerequisite has the following results:
A new commit is created. You can check it on the Commits tab.
The prerequisite is displayed in the Prerequisites section on the Properties tab.
The prerequisites key and value property are added to the .gcts.properties.json le in the remote repository.
If the repository is cloned to another ABAP system, the prerequisite is checked. If the speci ed version of the software
component, or a higher version, isn't installed in the system, gCTS doesn´t clone the repository.
Related Information
The gCTS Properties File
Set the Repository Layout
You can display the layout properties of a repository, and change them if necessary.
Prerequisites
You're in the gCTS app, on the Properties tab of a repository.
Your repository is of the type Development.
 Caution
It’s possible to change the layout for repositories of the type Provided too. However, do this only to align the layout
with the Development repository and to make sure that the layout is the same in all ABAP systems that use the
repository.
Apart from the initial commit - which just contains a README le -, no commit was activated for this repository yet.
After making the rst commit, don’t change the layout properties, because this will lead to inconsistencies in the
repository.
Context
This is custom documentation. For more information, please visit the SAP Help Portal
120
11/15/2023
If the repository has multiple branches, you change the layout properties for the active branch of the repository.
Procedure
1. Go to the Layout section of the Properties tab.
In the Layout section, the following information is displayed:
Field
Description
Version
Internal version number of the layout format used for this repository. You can’t change it.
Possible values:
1: Files of ABAP objects are stored in XML format.
3: By default, les of ABAP objects are stored in JSON format. The format can be changed to
XML. The meta information path can be changed. Table content support can be switched off.
4: Properties of version 3, plus the option to enter a Subdirectory path.
New repositories are created with the newest layout version.
 Note
For repositories of version 1, only the version information is displayed.
Version 2 was skipped.
File Format
In gCTS, the ABAP development objects are converted into les that can be stored in Git repositories.
Possible values: JSON | XML
By default, the le format of new repositories is JSON.
Meta Information Path
Directory where the meta information les are stored. The default path is .gctsmetadata/. You can
change the default path.
Subdirectory path
Target directory for object deployment within an existing remote repository.
Examples: src/ABAP/
You can use this parameter to specify in which directory of this repository the ABAP objects are stored.
If this directory doesn’t exist in the repository, gCTS creates it using the value you specify here. For
example, use ABAP/, if you use a monolithic repository (that is, a repository for different applications),
to specify the directory for the ABAP content.
 Note
The value you enter here is stored as the read-only con guration parameter VCS_TARGET_DIR.
Table Content Support
This property is used for Customizing data (table content).
Possible values: ON | OFF
ON is the default value.
2. If you've made any changes to the layout properties, choose Save to save your changes.
Results
Saving changes to the Layout has the following results:
A new commit is created with the generated text modify repository layout. You can check it on the Commits tab.
The changed values are changed in the repositoryLayout property of the .gcts.properties.json le in the
remote repository.
This is custom documentation. For more information, please visit the SAP Help Portal
121
11/15/2023
Related Information
Con guration Parameters for Repositories
The gCTS Properties File
Use the Collaboration Tab of a Repository
On the Collaboration tab, you can add teams or individual users as collaborators to the repository.
Prerequisites
An ABAP user needs access to a local repository. For more information, see Collaboration Permissions.
Context
You can manually add teams and individual users to a repository and grant them the permissions they require to work in this
repository.
For repositories on GitHub and GitLab: You can synchronize teams and collaborators and their permissions from the remote
repository to the local repository.
Procedure
1. In the gCTS app, in the Repository view, choose the Collaboration tab.
2. On the Collaboration tab, you can do various tasks.
Adding Teams or Individual Collaborators to Repositories
By adding teams or individual collaborators to a local repository, you enable users to collaborate in a repository.
Synchronizing Teams or Collaborators
You can synchronize teams and individual collaborators, and their collaboration permissions in a remote GitHub or
GitLab repository with the local repository on an ABAP system. The remote repository is the single source of truth.
Adding Teams or Individual Collaborators to Repositories
By adding teams or individual collaborators to a local repository, you enable users to collaborate in a repository.
Prerequisites
Your user has Admin permissions in the repository to which you want to add collaborators.
To assign a team to a repository, a team has been created in advance.
For more information, see Use the Teams Tab.
To assign an individual collaborator to a repository, your user needs the authorization object S_USER_GRP with eld
CLASS = SUPER and eld ACTVT = 03. The authorization object is part of the SAP_BC_GCTS_ADMIN role.
For more information, see Roles in gCTS.
Procedure
This is custom documentation. For more information, please visit the SAP Help Portal
122
11/15/2023
1. In the gCTS app, in the Repository view, go to the Collaboration tab.
2. To add a team as collaborators to the repository, in the Teams section, choose Add.
a. Enter the name of an existing team.
Start typing the rst characters of the team name. The autocomplete function displays all teams that exist in this
system.
b. Select the permission that you want to grant the team.
For more information about the available permissions, see Collaboration Permissions.
c. Choose Save.
3. To add an individual collaborator to the repository, in the Collaborators section, choose Add.
a. Enter an existing ABAP user name in the Collaborator eld.
b. Select the permission that you want to grant to this user.
For more information about the available permissions, see Collaboration Permissions.
c. Save your work.
Results
The team members or individual users are added as collaborators to the repository with the selected permission.
Note that the corresponding users on the Git server also require permissions in the remote repository. For more information,
see Authorization Concept in gCTS.
Synchronizing Teams or Collaborators
You can synchronize teams and individual collaborators, and their collaboration permissions in a remote GitHub or GitLab
repository with the local repository on an ABAP system. The remote repository is the single source of truth.
Prerequisites
You have the authorizations of the authorization object S_GCTS_SYS with ACTVT = All Activities, or of the authorization
object S_GCTS_R with ACTVT = All Activities in the ABAP system. For more information, see Authorization Objects in
gCTS.
The repository where you want to run the synchronization is hosted on a GitHub or GitLab server.
You're a collaborator in the remote repository.
You've speci ed authentication to the Git server where the remote repository is hosted using a personal access token.
To synchronize users, the following requirements must be met:
In the ABAP system, an ABAP user exists. In transaction SU01, an email address exists for the ABAP user.
On the Git server, a Git user exists. The Git user has de ned a public email address in both places:
In the user´s account settings.
 Note
For GitHub, the process is described in the GitHub Docs
. Search for the topic Adding an email
address.
This is custom documentation. For more information, please visit the SAP Help Portal
123
11/15/2023
As Public email in the user´s Public pro le.
Context
gCTS checks which teams and collaborators are assigned to the remote repository, and then synchronizes them with the teams
and collaborators assigned to the local repository. The corresponding permissions are also synchronized. It's possible to
synchronize only the permissions of users in the local repository. Assignments and permissions are changed only in the local
repository. No changes are made in the remote repository.
The synchronization is based on the following criteria:
Teams: Matching names of teams in the remote repository and local repository
 Note
Because teams in remote repositories are always part of an organization, gCTS maps the name of a remote team to
the name of a local team by adding the name of the team's organization with a hyphen (-) as a pre x to the team
name. The format is as follows:
Remote: <teamname> = Local: <orgname>-<teamname>
 Example
TestTeam in the Samples org matches the local team Samples-TestTeam .
Collaborators: Matching email address of ABAP user and user on the Git server
The email address of the collaborator exists both in the ABAP system and on the Git server, as described previously in
the Prerequisites section. If an email address doesn't exist where required, gCTS can't synchronize the user.
Procedure
1. In the gCTS app, in the Repository view, go to the Collaboration tab.
To synchronize teams of the remote repository with the local repository, in the Teams section, choose
Synchronize.
To synchronize individual collaborators of the remote repository with the local repository, in the Collaborators
section, choose Synchronize.
The Synchronize Collaborators dialog opens.
2. Select a Synchronization Method.
The following methods are available:
Keep Local, Add Remote
If the local repository has collaborators or teams assigned that aren't part of the remote repository, they remain
in the local repository.
Remove Local, Add Remote
If the local repository has collaborators or teams assigned that aren't part of the remote repository, they're
removed from the local repository.
Update Permissions Only
Only the permissions of existing collaborators or teams are synchronized. No teams or collaborators are added to
the local repository or removed from it.
3. Optional: Extend the synchronization scope.
This is custom documentation. For more information, please visit the SAP Help Portal
124
11/15/2023
If the synchronization scope is teams, you can extend the scope of the team by individual collaborators. If the
synchronization scope is individual collaborators, you can extend the scope of the individuals by teams.
4. Optional: To disable the simulation run, deselect the Run Simulation checkbox.
By default, gCTS does a simulation run of the synchronization with the options speci ed, and displays the results. No
data is changed during a simulation run.
5. If you've left the default simulation unchanged, on the Simulation of Synchronization dialog box, check that the result of
the simulation run meets your expectations.
6. To run the synchronization with the speci ed options, choose Synchronize.
Results
Permissions and assignments of teams and collaborators are changed in the local repository depending on the options
speci ed.
You can check the result on the Collaboration tab. For more information about how the permissions in remote repositories are
mapped to local repositories, see Background Information: Mapping of Git Permissions to Permissions in gCTS.
When you synchronize teams, the following situations can occur:
If a team exists with a matching name in the local and the remote repository, members that exist only in the remote
team are added to the local team. The synchronization options Keep Local, Add Remote and Remove Local, Add Remote
allow you to select whether users who are members only of the local team are to be kept in the local repository, or
removed from it.
If a team exists in the remote repository only, or if a team name in the local repository doesn't match the name in the
remote repository, gCTS creates a new team in the local repository with the following name: <orgname>-<teamname>.
gCTS adds all members of the remote team as members to the local team.
If individual team members of the remote team don't exist in the ABAP system, the team is created in the local
repository with only the members that have a corresponding user in the ABAP system.
 Caution
In the following situations, gCTS doesn't display any warning messages:
If users can't be found in the ABAP system.
Make sure that all users exist in the ABAP system and on the Git server, and that their email addresses exist where
required, as described in the Prerequisites section.
If you´ve selected the Remove Local, Add Remote option:
If collaborators or teams are found that are part of the local repository, but not of the remote repository, their
assignments are removed from the local repository.
If you have Admin collaboration permissions in the local repository, but you don't have a user in the remote repository,
and gCTS can't determine whether any synchronization is required. gCTS displays the message No changes are
applied.
Make sure that you have sufficient authorizations and users with data entered in all the places where required, as
described in the Prerequisites section.
Background Information: Mapping of Git Permissions to
Permissions in gCTS
This is custom documentation. For more information, please visit the SAP Help Portal
125
11/15/2023
The following tables provide an overview of how permissions in remote repositories are mapped to collaboration permissions in
local repositories.
GitHub Permissions
gCTS Collaboration Permissions
Admin
Admin
Write/Maintain
Write
Triage/Read
Read
GitLab Permissions
gCTS Collaboration Permissions
Owner
Admin
Developer/Maintainer
Write
Minimal access/Guest/Reporter
Read
Related Information
Collaboration Permissions
Use the Tags Tab of a Repository
The Tags tab provides an overview of the tags of a repository. You can create new tags, compare the object differences of
selected tags, activate tags, and delete existing tags.
Context
A tag allows you to indicate the importance of a commit by creating a pointer to this commit. For example, you can use tags to
mark a version of your repository. Tagging a commit is useful, for example, if your repository has a dependency on another
repository, and you want to ensure that you can create a dependency to a stable commit.
For more information about tags in Git, refer to Git tagging.
On the Tags tab, all tags of all branches of the repository are displayed in alphabetical order.
Tags that you create in the semantic versioning format for the current commit in the active branch of a repository generate a
new commit that updates the version of the repository in the .gcts.properties.json le.
Procedure
1. In the gCTS app, in the Repository view, choose the Tags tab.
2. On the Tags tab, you can do various tasks.
Create Tags
You create tags for the current commit in the active branch of a repository.
Activate Tags
By activating a tag, you pull the reference commit of the tag to the system.
Compare Tags
This is custom documentation. For more information, please visit the SAP Help Portal
126
11/15/2023
To nd out the object differences between the reference commit of a selected tag and the active tag, you can use this
function.
Create Tags
You create tags for the current commit in the active branch of a repository.
Prerequisites
You're in the gCTS app, on the Tags tab of a repository. The repository is on the latest commit in the branch in which you want to
create a tag.
Procedure
1. To create a new tag, choose Create.
2. In the dialog box, enter the Name of the new tag.
Note the following points with regard to naming:
Tag names must comply with the Git speci cation of well-formed reference names. For example, you can't use
spaces and special characters. For more information, refer to git-check-ref-format.
If you enter a tag name in the semantic versioning format, a new commit is created in the active branch of the
local repository. The new commit is used as the reference commit for the new tag. The version of the repository in
the gCTS properties le is updated with the version used as the tag name.
 Example
1.1.0
v1.0.3
 Recommendation
To create a tag indicating a version of your repository, use the semantic versioning format. For more
information, see https://semver.org/
.
If you enter a tag name that doesn't follow the semantic versioning format, the current commit of the active
branch in the local repository is taken as the reference commit. No new commit is created for the tag.
If you create a tag for a previous commit of a repository, no new commit is created and the version in the gCTS
properties le isn't updated, even if you use the semantic versioning format.
 Recommendation
Always create a tag for the latest commit of a repository.
3. Enter a description of the tag.
4. Choose Create.
Results
A tag is created in the local repository.
If you've used a tag name in the semantic versioning format, a new commit was created as the reference commit of the tag. The
new commit is pushed to the remote repository.
This is custom documentation. For more information, please visit the SAP Help Portal
127
11/15/2023
You can check the result of the tag creation in the following places:
On the Tags tab:
The new tag is displayed as the active tag together with the description and the reference commit.
On the Commits tab:
The rst time a tag is created in a repository, a Tag column appears in the commits list displaying the name of the
tag and the reference commit.
If you've used a tag name in the semantic versioning format, the new commit is displayed as the reference
commit of the tag with a generated commit message.
In the remote repository
If you've used a tag name in the semantic versioning format, the version of the repository in the gCTS properties le of
the branch that is active in the local repository is updated with the version of the tag.
On the Logs tab:
Creating a tag is logged as a CREATE_TAG process.
 Note
If you've disabled gCTS’s automatic pull and push behavior, the new commit is only available in the local repository. Manually
push the commit to the remote repository. This will update the version of the repository in the gCTS properties le in the
branch where the tag was created.
To delete an existing tag, choose
(Delete Tag).
Deleting a tag is logged as a DELETE_TAG process. You can check the log on the Log tab.
Related Information
The gCTS Properties File
Activate Tags
By activating a tag, you pull the reference commit of the tag to the system.
Prerequisites
You're in the gCTS app, on the Tags tab of a repository.
Context
Activating a tag corresponds to a pull action that imports object differences depending on the con guration of the repository.
For more information, see Pull Commits.
Procedure
1. Verify that the tag that you want to activate exists in the active branch of the repository.
If the tag doesn't exist in the active branch, switch to this branch before activating the tag.
This is custom documentation. For more information, please visit the SAP Help Portal
128
11/15/2023
For more information, see Switch the Branch of a Repository.
2. In the line of the tag that you want to activate, choose
(Activate Tag).
Results
The system is set to the reference commit of the tag.
The Current Commit in the header displays a link to the reference commit.
The reference commit that was pulled is displayed in bold characters because it's now the active commit of the local
repository.
The status of the repository is CHECKOUT.
You can check the result in the following places:
On the Log tab:
See the logs for the PULL_BY_COMMIT process.
On the Activities tab:
See the status of the Pull activity and the log of the transport request that was created for the import.
 Note
If the import generates a return code that is equal to or greater than 8, by default gCTS returns an error message, and the
local repository remains on the old commit, even though the import has run. In such an error situation, carefully analyze the
log of the transport request. To suppress the error message and classify the return code as tolerable, you can adjust the
VCS_IMPORT_ERROR_LEVEL con guration parameter. For more information, see VCS_IMPORT_ERROR_LEVEL.
Compare Tags
To nd out the object differences between the reference commit of a selected tag and the active tag, you can use this function.
Prerequisites
You're in the gCTS app, on the Tags tab of a repository.
Context
You can also use this function, if there´s only one tag in the repository that isn't the active one to display the object differences
between the reference commit of the tag and the current commit.
 Recommendation
Use this function before you activate a tag.
Procedure
In the line of the tag that you want to compare with the current commit, choose
(Compare Object Differences of Tags).
Results
This is custom documentation. For more information, please visit the SAP Help Portal
129
11/15/2023
The system compares the objects of the reference commit of the selected tag with reference commit of the active tag, or with
the current commit, if no active tag exists. As a result, the system displays the objects that differ between the commits and the
type of the change (object is created, deleted, or modi ed). This function doesn't show detailed changes in objects. For in-depth
comparison, use the speci c commit comparison function offered by your Git provider.
Use the Jobs Tab of a Repository
The Jobs tab provides an overview of scheduled background jobs of a repository. It allows you to create new jobs, delete existing
ones, and navigate to the detailed log of a job.
Context
Scheduling background jobs allows you to move long-running or resource-intensive activities to the background, or to times
when the system load is low. For more information, see Background Processing: Concepts and Features.
Procedure
1. In the gCTS app, in the Repository view, choose the Jobs tab.
All scheduled jobs in status Running or Scheduled are displayed by default.
For each job, the following additional information is displayed:
Column
Description
Job ID
Type
Type of job. The following types exist:
Pull | Switch Branch | Clone
 Note
A scheduled job of an Update to Latest action is of type Pull without any parameter speci ed.
Parameter
The parameter used for the scheduled job type when the job is run. The following parameters exist:
Commit ID of the pulled commit | Name of the branch to switch to
Scheduled For
Date and time when the scheduled job is started.
Created By
User who scheduled the job.
Status
Status of the job. The following statuses exist:
(Action is scheduled) | blue
nished)
blue
(Scheduled action was run) | green
(Scheduled action was
2. On the Jobs tab, you can do various tasks:
Task
Function in the gCTS App
Description
Create new background jobs.
Create
Schedule Background Jobs for gCTS Activities
Delete existing background jobs.
Delete
Deleting a job is logged as a DELETE_JOB action on the
Log tab.
Filter displayed background jobs.
(Filter)
Use the lter to display Finished jobs or deselect
activity types.
This is custom documentation. For more information, please visit the SAP Help Portal
130
11/15/2023
Task
Function in the gCTS App
Display the logs of a scheduled action
Description
To navigate to the log of the scheduled action, click
anywhere in the row of the log.
Schedule Background Jobs for gCTS Activities
Scheduling a long-running activity as a background job allows you to continue working on other tasks in the gCTS app.
Schedule Background Jobs for gCTS Activities
Scheduling a long-running activity as a background job allows you to continue working on other tasks in the gCTS app.
Prerequisites
Depending on the activity that you want to schedule as a background job, you're on the Commits, Branches, or Jobs tab of a
repository.
Context
The following activities in gCTS can be scheduled as background jobs:
Clone a repository
This activity can only be scheduled once.
Pull a commit
Update a repository to the latest commit
This activity can only be scheduled on the Commits tab.
Switch the branch of a repository
Procedure
1. If you're on the Jobs tab, proceed as follows:
a. Choose Create.
b. On the Schedule Job dialog, select or enter the following information:
Field
Description
Type
Select the type of action of the scheduled job.
If the repository wasn't cloned to the ABAP system, only the Clone Repository type is
displayed.
If the repository was cloned and only one branch exists, the Pull Commit type is selected by
default.
If the repository was cloned and multiple branches exist, the Switch Branch type is selected
by default.
This is custom documentation. For more information, please visit the SAP Help Portal
131
11/15/2023
Field
Description
Branch
This eld is displayed, if Switch Branch is selected.
Select the branch that you want to switch to.
Commit
This eld is displayed, if Pull Commit is selected.
Enter an existing commit of the active branch of the local repository that you want to pull.
 Note
You only need to enter sufficient characters of the commit ID to uniquely identify it.
If you enter a commit ID that doesn't exist, you get an error message that the commits couldn't be
compared. Scheduling is aborted.
2. If you are on one of the Commits or Branches tabs, choose the dropdown arrow ( ) that you can nd next to the button
or icon that triggers the respective activity (Clone, (Pull selected commit to system’s local repository (object
difference is imported depending on the con guration)), Update to Latest, (Branch of local repository will be switched
to selected branch (object difference will be imported depending on con guration).) ).
3. Select a start time or leave the default Immediate Start time selected.
4. Con rm your selection by choosing Schedule in Background.
Results
The corresponding activity is scheduled as a background job with the following names.
Clone: GCTS_CLONE_REPO
Switch branch: GCTS_SWITCH_BRANCH
Pull/ Update to Latest: GCTS_PULL_COMMIT
 Note
The job is scheduled with your local time. However, on the Jobs and Log tabs, it's displayed with the server time. Take
into account that there can be a difference between your local time and the server time.
The changes introduced after a scheduled activity has run aren't automatically re ected in the gCTS app. To refresh
the screen, use
(Refresh).
You can check the result in the following places:
On the Jobs tab.
All scheduled jobs in a Scheduled or Running status are displayed by default. You can adapt the lter settings. For more
information, see Use the Jobs Tab of a Repository.
On the Log tab.
Click anywhere on a job entry on the Jobs tab to open the corresponding log entry for the related process on the Log tab.
For more information, see Use the Log Tab of a Repository.
 Note
It's important that you check the log entry of a scheduled activity after it has run. If errors occur during the activity,
they're displayed in the log. The Jobs tab only displays the status of the job.
This is custom documentation. For more information, please visit the SAP Help Portal
132
11/15/2023
In the ABAP system in the Job Overview (transaction SM37).
Search fo the name of the scheduled job that you can nd in the log in the gCTS app.
Related Information
Clone the Remote Git Repository to the ABAP System
Pull Commits
Switch the Branch of a Repository
Update ABAP Target Systems
To update an ABAP target system with the current state of development of the ABAP development system, you have different
options.
Prerequisites
You’ve con gured gCTS in an ABAP system that you want to use as a target system, for example, a quality, test, or
production system. For more information, see Con guring Git-Enabled Change and Transport System.
You´ve created the repositories with which you want to update the ABAP target system and cloned them to it.
Context
You update ABAP target systems by pulling ABAP objects from your remote Git repository to the ABAP system in one of the
following ways:
Procedure
1. Manually pull updates in target systems from repositories that have been created on the target system and cloned to it.
You can choose to update target systems with the most recent commit or any selected commit of a remote repository.
For more information, see Pull Commits.
2. Use a CI pipeline to enable an automated update of target systems where remote Git repositories have been created.
For example, you can use the gctsDeploy step of project "Piper" to pull the current commit from the remote Git
repository to the local repository on the target system.
For more information, see Integration of gCTS in CI Pipelines.
Integration of gCTS in CI Pipelines
To leverage the functions of Git-enabled Change and Transport Management (gCTS), we recommend that you integrate gCTS
into CI pipelines.
SAP provides a sample CI pipeline scenario for gCTS using Project "Piper". You can use it as a template and adapt it to your
needs. For more information, see Set up a Pipeline-Based ABAP Development and Testing Process Using Git-Enabled Change
and Transport System
.
The following gCTS Library steps are used in the sample scenario:
gCTSDeploy
This is custom documentation. For more information, please visit the SAP Help Portal
133
11/15/2023
For all deployment-related actions, we recommend that you use the gCTSDeploy step.
The gCTSDeploy step runs the following actions:
It deploys a remote Git repository to a local repository on an ABAP system and imports the content in the ABAP
database.
If the repository doesn't yet exist in the system, the step creates it.
If the repository already exists on the ABAP system, the step runs the remaining step actions, depending on the
parameters provided for the step. For example, these step actions might be to deploy a speci c commit to the ABAP
system, or to deploy the current commit of a speci c branch.
You can use the gCTSDeploy step as of SAP S/4HANA 2020.
For more information, see gctsDeploy
.
gctsExecuteABAPQualityChecks
To run ABAP unit tests and ATC checks for your developments, you can use the gctsExecuteABAPQualityChecks
step.
It runs ABAP unit tests and ATC (ABAP Test Cockpit) checks for a speci ed object scope.
gCTSRollback
To roll back to a speci ed commit, for example, if errors occur in the quality checks, you can use the gCTSRollback
step.
Troubleshooting Git-Enabled Change and Transport System
For information about troubleshooting gCTS, see the guided answer Troubleshooting Git-Enabled Change and Transport System
.
Checking the gCTS Observer Job
The gCTS observer job is scheduled as part of the Enable gCTS wizard process.
Context
The ABAP user who uses the wizard schedules the job. The name of the job is SCTS_ABAP_VCS_IMPORT_OBSERVER. In the
following situations, you may want to check the observer job:
The Health Check displays that no observer job is scheduled. You want to nd out whether the job exists in the status
Released.
You want to add the user who scheduled the observer job as a collaborator to your remote repository to enable write
access. You want to nd out who scheduled the job.
Proceed as follows:
Procedure
1. In SAP GUI, start transaction SM37.
2. Enter the following selection criteria:
This is custom documentation. For more information, please visit the SAP Help Portal
134
11/15/2023
Field Name
User Input
Job Name
SCTS_ABAP_VCS_IMPORT_OBSERVER
User Name
If you know the user who scheduled the job, enter the user name. Alternatively, you can use * to search
for all users.
Job Status
You can leave the default selection unchanged.
Job Start Condition
Select a valid date range.
As input for the eld Or after event, select the value SAP_TRIGGER_VCS_IMPORT from the dropdown
list.
3. Choose Execute.
The result shows the job in the status Released.
The user who scheduled the job is displayed in the Job Created By column.
If no job is displayed, or if the job has a status other than Released, it means that the observer job is not scheduled and
the system wasn't initialized.
Related Information
Enable Git-Enabled Change and Transport System in an ABAP System
The gCTS Properties File
The .gcts.properties.json le contains the properties of a Git repository that was cloned to an ABAP system.
It's created in the root directory of the remote repository when the rst commit of a cloned repository is pushed to the remote
repository. There´s one properties le for each branch of the repository.
The following sample le shows the different properties and their keys and values:
 Sample Code
{
"name":"testrepo",
"version":"1.0.0",
"description":"testrepo",
"configurations":[{"key":"VCS_AUTOMATIC_PULL","value":"false"},{"key":"VCS_AUTOMATIC_PUSH","value
"dependencies":[{"name":"com.github.testdependency","version":"1.0.1","url":"https://github.com/t
"prerequisites":[{"component":"ADDON","release":"100","supportPackage":"01"}],
"repositoryLayout":{"formatVersion":4,"format":"json","objectStorage":"plain","metaInformation":"
}
Properties of the gCTS Properties File
The following table contains more information about the individual properties of the gCTS properties le:
Property
Description
name
Name of the repository.
This is custom documentation. For more information, please visit the SAP Help Portal
135
11/15/2023
Property
Description
version
Version of the repository.
description
Description of the repository.
configurations
Con guration parameters and their values that are set to global in the ABAP source system. This
property can contain multiple key-value pairs.
For more information, see Edit Con guration Parameters for Repositories.
dependencies
Dependencies of the repository as set in the ABAP source system. This property can contain multiple
key-value pairs.
For more information, see Set Dependencies of a Repository.
prerequisites
Prerequisites of the repository as set in the ABAP source system. This property can contain multiple
key-value pairs.
For more information, see Set Prerequisites of a Repository.
repositoryLayout
Layout properties of the repository as set in the ABAP source system.
 Note
The value of the objectStorage parameter can't be changed in the gCTS app.
For more information, see Set the Repository Layout.
 Caution
Only change entries in the .gcts.properties.json le, if you're an expert user, or, in error situations, if SAP Support
asks you to do so. Otherwise, this leads to inconsistencies both in your repository and in the ABAP systems to which the
repository is cloned.
If you've changed any properties of the repository, both in the gCTS app on your local ABAP system and in the remote
repository, it's possible that a con ict occurs in the .gcts.properties.json le. In this case, the property le is
displayed as a con icting le on the Objects tab of your repository. To resolve the con ict, proceed as described under
Resolve Con icts.
This is custom documentation. For more information, please visit the SAP Help Portal
136