ABAP Cloud Course

Appearance

Workshop Companion — Git & GitHub for ABAP Cloud ​

This companion expands Workshop — Git & GitHub for ABAP Cloud.

Workshop step 3 of 3

Use this page after Step 1 — Learn and Step 2 — Lab, or return whenever you need a reference. After this checkpoint, continue to Foundation Lesson 2.

It is a student-facing reference for concepts and problems that are useful but too detailed for the main guided workflow.

Use it when you need to understand:

text
how abapGit fits into ABAP Cloud
why ABAP packages are not local Git folders
how serialized files represent ABAP objects
what .abapgit.xml does
how imports behave
why activation order matters
which object types can be transferred
how Git differs from transports
how GitHub authentication should be handled

1. The architecture in one diagram ​

The complete mental model is:

text
Developer
   ↓
Eclipse + ADT
   ↓
ABAP Cloud Project
   ↓
ABAP backend repository
   ↓
ABAP package + repository objects
   ↓
SAP-supported abapGit integration
   ↓
serialized files
   ↓
Git commits
   ↓
GitHub remote repository

The key idea is:

The ABAP backend remains the development environment. GitHub stores a serialized Git representation of supported ABAP repository objects.

2. Why a normal local Git tutorial is not enough ​

A standard Git tutorial often assumes:

text
editor
  ↓
local folder
  ↓
.git directory
  ↓
git CLI

ABAP Cloud in ADT uses a different development repository model:

text
ADT editor
  ↓
ABAP backend repository

ABAP objects have repository metadata and activation semantics that do not map perfectly to plain files.

abapGit handles the bridge.

3. Git concepts worth knowing now ​

The workshop deliberately teaches a small Git subset first.

Repository ​

A project history plus its tracked files.

Working change ​

A source state that differs from the repository's last known state.

Stage ​

Selection of changes for the next commit.

Commit ​

A named snapshot/change set in history.

Push ​

Transfer of commits to a remote Git repository.

Pull/import ​

Transfer of remote repository state into a development environment.

Diff ​

A comparison showing how one version differs from another.

Branch ​

A named line of development.

Students should understand these before learning merges, rebases, cherry-picks, or conflict-resolution strategies.

4. Git commit vs ABAP version vs transport ​

These concepts are easy to confuse.

ConceptPurpose
ABAP active/inactive versionControls executable/active repository state in the ABAP system
Git commitRecords a source-change snapshot in Git history
Transport requestRecords/moves ABAP development changes through the SAP lifecycle

They can describe the same development work from different perspectives, but they are not interchangeable.

5. What SAP currently recommends for lifecycle ​

For SAP BTP ABAP Environment, SAP currently recommends:

text
gCTS / Manage Software Components

for the regular development-system lifecycle within the same global account, such as:

text
DEV → TEST → PROD

SAP documents abapGit for scenarios such as:

text
migration
source export
sharing
open source
cloud-to-cloud transfer across independent accounts
partner/customer transfer
distributed special development scenarios

Therefore:

text
abapGit is useful

but:

text
abapGit is not the standard replacement for landscape transports

6. gCTS in plain language ​

gCTS means Git-enabled Change and Transport System.

In BTP ABAP Environment, it is surfaced through lifecycle tooling such as:

text
Manage Software Components

A software component groups ABAP packages for lifecycle management.

When transport requests are released in the normal software-component workflow, the lifecycle system uses Git-based infrastructure under the hood.

Students do not need to administer gCTS in this workshop.

The important distinction is:

text
abapGit
  = explicit source import/export bridge

gCTS
  = SAP-controlled lifecycle/transport mechanism

7. Bring Your Own Git is another separate concept ​

SAP also supports Bring Your Own Git (BYOG) for software components in Manage Software Components.

BYOG connects a software component lifecycle to a customer-controlled Git provider.

It is not the same workflow as:

text
abapGit Repositories view
Stage and Push

BYOG is an advanced lifecycle/DevOps topic.

Do not combine its rules with the workshop's abapGit workflow.

8. SAP-supported cloud integration vs community abapGit ​

abapGit originated as a community open-source project.

For SAP BTP ABAP Environment, SAP provides a separate cloud/SAP-supported integration/version.

This distinction matters for support.

Conceptually:

text
community abapGit
  → community-maintained distribution, common in on-premise systems

SAP BTP ABAP Environment abapGit integration
  → SAP-provided cloud integration usable from ADT

The ADT plug-in is the developer-facing bridge for the cloud workflow.

9. The ADT plug-in ​

The abapGit Repositories ADT plug-in can be installed from:

text
https://eclipse.abapgit.org/updatesite/

SAP's current installation guidance uses:

text
Help
  → Install New Software...

and then selects the abapGit feature for ABAP Development Tools.

Once installed, the view can be opened from:

text
Window
  → Show View
  → Other...
  → ABAP
  → abapGit Repositories

10. Package-to-repository mapping ​

An abapGit repository is associated with a root/top ABAP package.

Subpackages can map to Git subfolders depending on the repository's folder logic.

The Git repository does not simply persist:

text
PACKAGE = ZFOO

as the only organization mechanism.

It serializes package metadata plus repository folder structure.

11. .abapgit.xml ​

.abapgit.xml is a special repository file used by abapGit.

It must live in the repository root.

It can contain project metadata such as:

text
master language
starting folder
folder logic
requirements
other repository settings

A typical repository uses a starting folder such as:

text
/src/

The workshop does not require manual editing of .abapgit.xml.

12. Folder logic ​

abapGit supports folder-mapping modes such as:

text
PREFIX
FULL
MIXED

These control how package hierarchy maps to repository directories.

For a beginner workshop, do not change folder logic unless there is a specific problem.

The important idea is:

text
ABAP package hierarchy
  ≠
Git folder hierarchy by simple string equality

abapGit performs a mapping.

13. Why repository files look unusual ​

ABAP repository objects are serialized into files named according to object type and part.

Common patterns can include:

text
<object>.<type>.<extension>
<object>.<type>.<part>.<extension>

Source may appear in:

text
.abap

Metadata may appear in:

text
.xml
.json

Some modern object types use ABAP File Format-related serialization.

The exact filename format is not the learning objective.

14. Why a class can create multiple files ​

An ABAP class may contain several repository parts.

Examples include:

text
main class source
metadata
local definitions
local implementations
test classes
macros

A serializer can store those as separate files to make source comparison easier.

Therefore:

text
ABAP object count

is not expected to equal:

text
Git file count

15. Package metadata files ​

You may see files such as:

text
package.devc.xml

These store package metadata.

abapGit repositories do not simply hard-code the target SAP package name as the repository's identity.

That supports installation into another compatible package hierarchy.

16. Supported ABAP object types ​

ABAP Cloud restricts abapGit import/export to a supported/released set of repository object types.

This set changes over time.

A modern course should therefore teach this rule:

Before depending on abapGit for a new artifact type, check the current SAP “Released ABAP Object Types” documentation.

Do not build a static list into your mental model.

17. Export behavior for unsupported objects ​

SAP documents that an export can warn and skip unsupported object types.

This means a successful push does not automatically mean:

text
every object in the package was exported

Always inspect:

text
stage result
warnings
repository content

when using unfamiliar object types.

18. Generated objects ​

Some ABAP artifacts are generated from source objects and intentionally are not serialized independently.

They can be regenerated by activation in the target system.

That is another reason not to use:

text
Git file count

as a naive measure of application completeness.

19. Import workflow reference ​

SAP's current cloud import workflow is:

text
1. Open ABAP Cloud project in ADT
2. Window → Show View → Other...
3. Open ABAP → abapGit Repositories
4. Select Clone (green +)
5. Enter repository URL
6. Select branch
7. Select target package
8. Select transport request
9. Finish

The repository must be reachable from the cloud environment.

20. Why the repository must be reachable ​

The ABAP cloud environment needs network access to the Git endpoint.

A Git server that exists only on an inaccessible private network cannot simply be reached from the cloud service.

SAP's import documentation explicitly notes that Cloud Connector is not used for this abapGit repository access scenario.

For a classroom GitHub repository, the standard GitHub HTTPS endpoint is appropriate.

21. Authentication with GitHub over HTTPS ​

GitHub has removed account-password authentication for Git operations over HTTPS.

When a client prompts for a GitHub password for an HTTPS Git operation, use an approved token/credential mechanism.

For a personal repository this often means:

text
username
+
personal access token

GitHub recommends fine-grained tokens where possible and minimum required permissions.

22. Token security ​

Treat a GitHub access token like a password.

Never store it in:

text
ABAP source
Git repository files
commit messages
README.md
screenshots posted publicly
course submissions

Use the shortest practical expiry and minimum permissions appropriate to the course.

If a token is exposed:

text
revoke/rotate first
clean history second

Removing the token from the latest file does not invalidate the leaked credential.

23. GitHub organizations can add policy ​

If the repository belongs to an organization, authentication may also depend on:

text
SSO authorization
organization token policy
fine-grained token approval
branch protection
repository permissions

The workshop cannot override organizational policy.

Follow the institution's GitHub configuration.

24. Public vs private repositories ​

Both can be valid depending on policy.

A private repository is usually preferable for graded student work.

A public repository is suitable only when the source is intentionally public.

Never make a repository public merely to avoid fixing authentication.

25. Stage and Push ​

The ADT package context menu can provide:

text
Stage and Push

This opens the workflow for reviewing changed/new/deleted ABAP development objects, selecting which changes belong in the next commit, entering a commit message, and transferring the commit to the remote repository.

The labels can vary slightly across versions, but the underlying workflow remains stable.

26. Why staging matters ​

Imagine your package has three changes:

text
A. Add route CDS model
B. Fix typo in old class
C. Half-finished experiment

One careless commit could include all three.

A deliberate staging workflow can produce:

text
Commit 1
Add route CDS model

Commit 2
Fix typo in carrier runner

and leave the unfinished experiment uncommitted.

This makes history useful.

27. Commit-message guidance ​

Prefer imperative or concise descriptive messages.

Examples:

text
Add route association model
Refactor carrier reader to CDS
Expose route service definition
Fix destination airport mapping

Avoid messages that describe your mood or file operation rather than the software change:

text
try again
upload
save
misc
final version

28. One commit should represent one logical change ​

This is not an absolute rule, but it is a strong default.

A useful commit can be understood and reviewed without unrelated noise.

For example:

text
Add booking semantic annotations

should not also contain:

text
unrelated class rename
experimental persistence table
UI draft

unless those changes are genuinely part of the same logical feature.

29. Push errors ​

A push can fail because of:

text
bad credentials
expired token
insufficient repository permission
network/certificate restrictions
remote branch state
unsupported object serialization

Diagnose the specific error rather than repeatedly trying random credentials.

30. Certificate trust ​

SAP BTP ABAP Environment controls which external certificate authorities it trusts.

For unusual enterprise Git servers, an administrator may need to review the certificate trust configuration.

GitHub's public endpoint normally uses widely trusted certificate authorities.

This is an advanced troubleshooting topic, not a normal lab step.

31. Imported objects are often inactive ​

SAP documents that imported objects are generally created/imported inactive when the object type supports inactive versions.

This is intentional.

The target ABAP system must verify:

text
syntax
released API usage
dependencies
repository consistency

through activation.

32. Dependency-aware activation ​

After import, mass activation can sometimes require more than one cycle.

SAP specifically documents examples such as:

text
DDIC/CDS dependency ordering
Service Binding after Service Definition

A practical activation strategy is:

text
1. activate foundational data objects
2. activate CDS dependency layers
3. activate classes/behavior depending on them
4. activate Service Definitions
5. activate Service Bindings
6. repeat Activate All when dependencies become resolvable

The exact application decides the real order.

33. Existing object conflicts ​

ABAP repository names are system-wide.

A repository containing:

text
ZCL_EXAMPLE

cannot safely be cloned into a different package in the same ABAP system if ZCL_EXAMPLE already exists.

This is why the workshop's mandatory lab does not perform a self-clone into a second package.

34. Import overwrites need care ​

SAP documents that importing remote content can overwrite local object changes.

Open transport/request locks can also prevent objects from being changed.

Before pulling/importing into a real shared development system:

text
review local changes
coordinate with teammates
understand locks/transports
understand repository state

Do not use pull as an experimental “undo everything” button.

35. Git is not backup magic ​

A GitHub repository is useful for source history, but a professional backup/lifecycle strategy also considers:

text
unsupported artifacts
configuration outside serialized ABAP objects
UI repositories
business configuration
external services
credentials/secrets
system-specific settings

Do not assume that cloning one abapGit repository recreates every aspect of an application landscape.

36. UI repositories are separate ​

SAP documents a separate lifecycle for Fiori/UI artifacts.

Later, when students create a UI application with SAP Fiori tools, the architecture can become:

text
Git repo A
  ABAP backend artifacts via abapGit

Git repo B
  UI project files via normal Git tooling

The backend repository and UI repository can evolve independently.

37. Service Bindings and imports ​

A Service Binding is dependent on its Service Definition and the underlying service model.

After import, activation should respect this dependency:

text
CDS
  ↓
Service Definition
  ↓
Service Binding

If the Service Binding fails activation immediately after import, activate the lower layers first and retry.

38. GitHub diff as a review tool ​

A GitHub commit diff helps answer:

text
What source changed?
Did unrelated files change?
Did metadata change as well as source?
Did a rename create expected serialized changes?

For ABAP developers, reading serialized diffs is a useful professional skill even if all actual code editing remains in ADT.

39. Do not manually “fix” XML metadata unless you understand it ​

A serialized object may contain metadata that is not obvious from the ABAP editor.

For this course:

text
edit object in ADT
activate it
stage serialized result

Do not use GitHub's editor to patch metadata files casually.

40. README is not an ABAP repository object ​

A GitHub repository can contain normal repository documentation files such as:

text
README.md
LICENSE
CHANGELOG.md

These files are not ABAP repository objects.

They belong to the Git project rather than the ABAP repository itself.

This is useful: Git can hold project documentation around the serialized ABAP source.

41. What to put in a course README ​

A useful README can include:

text
project purpose
ABAP Cloud environment requirement
package/object naming convention
installation/import notes
required SAP demo content
lesson/workshop scope

Never put:

text
credentials
tokens
private tenant URLs if policy forbids them
personal secrets

42. Branches: useful but deferred ​

Branches are useful for parallel lines of work.

However, branching in an ABAP team is not just a Git syntax problem.

Teams must also coordinate:

text
ABAP object ownership
system state
transports
package organization
merge/conflict strategy

That is why the workshop teaches branch vocabulary but not a mandatory merge exercise.

43. Merge conflicts ​

A merge conflict happens when Git cannot automatically reconcile competing changes.

For serialized ABAP source, conflicts can involve:

text
source files
metadata files
multiple files representing one ABAP object

Conflict resolution should be handled carefully because a syntactically valid Git merge can still produce an invalid ABAP repository object after import.

This is an advanced workshop topic.

44. Team workflow guidance ​

For a classroom shared system, avoid having several students push the exact same ABAP object names to one repository without a defined team process.

A clean learning setup is:

text
student/group-specific ### suffix
student/group-specific package
student/group-specific Git repository

This matches the naming strategy already used by the course.

45. Repository scope guidance ​

Prefer one repository for one coherent ABAP source package/product area.

Avoid:

text
one Git repo for every individual class

and avoid:

text
one enormous repo for unrelated course exercises from every student

A repository should represent a meaningful source unit.

46. When to commit during later course lessons ​

A good cadence for a RAP project might be:

text
commit: Add persistence table
commit: Add root CDS model
commit: Add managed behavior
commit: Add projection layer
commit: Expose OData V4 service
commit: Add validation

This produces a useful evolution history.

47. What not to commit ​

Do not commit half-working source simply because class time is ending unless the workflow explicitly allows work-in-progress commits.

For a beginner course, prefer commits where:

text
syntax is checked
objects are activated
basic test/preview runs

This makes history easier to reuse.

48. Suggested commit checklist ​

Before commit:

text
[ ] intended objects saved
[ ] intended objects activated
[ ] basic execution/preview succeeds
[ ] staging contains only related changes
[ ] no secrets visible
[ ] commit message describes change

After push:

text
[ ] commit appears on GitHub
[ ] expected files changed
[ ] no unrelated files included
[ ] no credentials or tenant secrets exposed

49. Reference: independent import exercise ​

If you later have access to a different ABAP development system, the full exercise can be:

text
1. Create/open target ABAP Cloud project
2. Open abapGit Repositories view
3. Choose Clone
4. Enter GitHub HTTPS repository URL
5. Select branch
6. Select target package
7. Select transport request
8. Finish import
9. Inspect import log
10. Activate imported objects
11. Resolve dependency activation order if required
12. Run the application/tests

Do not use the same target system if the repository's object names already exist there.

50. Reference: example first commit ​

ABAP change:

abap
out->write( 'Git workshop - version 1' ).

Commit message:

text
Add initial ABAP Cloud Git workshop example

This is a coherent initial history point.

51. Reference: example second commit ​

ABAP change:

abap
out->write( 'Git workshop - version 2' ).
out->write( 'Second commit from ADT' ).

Commit message:

text
Update Git workshop console output

GitHub should show the source difference between the two commits.

52. Troubleshooting — abapGit view missing ​

Check:

text
Help → About Eclipse IDE → Installation Details

or attempt:

text
Help → Install New Software...

with the abapGit ADT update site.

Restart Eclipse after installation when requested.

53. Troubleshooting — Stage and Push missing ​

Check:

text
abapGit ADT plug-in installed?
correct ABAP Cloud project selected?
package selected rather than an arbitrary editor node?
backend supports the integration?

If the classroom image is centrally managed, ask the instructor to confirm plug-in provisioning.

54. Troubleshooting — authentication failed ​

Check:

text
HTTPS URL correct?
GitHub username correct?
token expired?
token has repository permission?
organization SSO authorization required?
repository private and inaccessible to account?

Do not use your ordinary GitHub account password for HTTPS Git operations.

55. Troubleshooting — repository not reachable ​

Check:

text
repository URL
internet accessibility
Git provider availability
certificate trust
organization network restrictions

Cloud-only private-network URLs generally require a supported architecture rather than assuming the ABAP system can see the same network as your laptop.

56. Troubleshooting — object skipped ​

Likely causes include:

text
unsupported object type
generated object
serializer restriction

Check SAP's current Released ABAP Object Types and the abapGit operation log.

57. Troubleshooting — imported object inactive ​

Expected for many object types.

Activate it.

If activation fails, inspect dependencies and activate lower layers first.

58. Troubleshooting — import count differs from export count ​

SAP explicitly documents this possibility.

Reasons include:

text
unsupported object types
generated artifacts
cloud release restrictions

Compare supported objects rather than assuming data loss immediately.

59. Troubleshooting — repository contains many files ​

Normal.

One ABAP object can serialize into multiple files.

Inspect object/type naming rather than counting files one-to-one.

60. Troubleshooting — GitHub shows an object deletion ​

Do not commit deletion until you know why it appears.

Confirm whether the ABAP object was:

text
deleted
moved/reassigned
renamed
made unsupported/unserializable

Deletion is a meaningful repository operation.

61. Troubleshooting — someone edited files on GitHub ​

Do not immediately pull into a shared ABAP system.

First review:

text
what changed
whether serialized metadata remains valid
whether local ABAP work exists
whether the remote edit was intentional

For this course, the intended direction is ADT → GitHub.

62. Professional boundary: source control vs deployment ​

A GitHub push does not deploy a running ABAP application to another system.

Deployment/lifecycle requires the appropriate ABAP system process.

Similarly:

text
GitHub commit

does not mean:

text
production release

Professional teams separate:

text
source version
quality checks
release process
transport/deployment

63. Professional boundary: backend vs UI ​

Later full-stack work may have:

text
Backend repository
  ABAP/CDS/RAP source

UI repository
  Fiori application project

A release may coordinate both repositories, but they retain separate source/lifecycle concerns.

64. Self-review questions ​

Before saying you understand the workshop, make sure you can answer:

text
Why isn't an ABAP package a normal local Git folder?
What does abapGit serialize?
What is staging?
What does a commit record?
What does push do?
Why doesn't Git replace ABAP activation?
Why doesn't Git replace gCTS transports?
What is .abapgit.xml?
Why can one class create several Git files?
Why can import require several activation cycles?
Why can clone-to-same-system create name conflicts?

65. Current references ​

SAP ​

GitHub ​

abapGit project documentation ​

Continue the course ​

You have completed the Git & GitHub checkpoint. Continue to Foundation Lesson 2 — Internal Tables, Loops & Methods →.