Workshop Lab — Git & GitHub for ABAP Cloud

This lab verifies that you can perform the Git workflow independently.

Workshop step 2 of 3

Complete Step 1 — Learn before starting this lab. When you finish, continue to Step 3 — Companion for the deeper reference and troubleshooting guide.

You will:

prepare a small ABAP package/object
      ↓
create a GitHub repository
      ↓
use abapGit from ADT
      ↓
stage + push an initial version
      ↓
inspect the repository
      ↓
make a second ABAP change
      ↓
stage + push again
      ↓
inspect history + diff
      ↓
explain Git vs ABAP transport lifecycle

The lab is designed to work with one SAP BTP ABAP Trial system.

You do not need a second ABAP system.

---

Lab information

Estimated time	60–90 minutes
Environment	SAP BTP ABAP Environment / Trial
Tools	Eclipse + ADT, abapGit Repositories plug-in, GitHub
Required output	GitHub repository with at least two meaningful commits
ABAP object	ZCL_GIT_LAB_### or an instructor-approved existing object
Recommended package	ZCOURSE_GIT_### or instructor-approved course package

---

Rules for the lab

Use your suffix

Replace:

###

with your student/group suffix.

---

Do not submit secrets

Never include:

GitHub password
personal access token
2FA code
recovery code
private key

in your source, repository, screenshots, or written answers.

If your instructor asks for evidence of successful authentication, show the resulting repository/commit—not the credential.

---

Edit ABAP in ADT

For this lab, make source changes in:

Eclipse + ADT

Do not edit serialized ABAP object files directly in GitHub.

---

Use meaningful commits

You need at least:

Commit 1 = initial working state
Commit 2 = a clear, intentional change

Avoid messages such as:

update
final
stuff
commit 2

---

Part 1 — Environment check

Confirm each item:

• ABAP Cloud Project opens in ADT.
• You can create/activate ABAP objects.
• You have access to a package you are allowed to use.
• You have a GitHub account.
• You can create a GitHub repository.

Record:

ABAP package:
Student/group suffix:

Do not record passwords or tokens.

---

Part 2 — Open the abapGit Repositories view

In Eclipse:

Window
  → Show View
  → Other...

Search for:

abapGit Repositories

If the view exists

Open it and continue.

If the view is missing

Install the ADT plug-in using:

Help
  → Install New Software...

Update site:

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

Install:

abapGit for ABAP Development Tools for Eclipse

Restart Eclipse if requested.

Record:

abapGit Repositories view available: Yes / No

---

Part 3 — Create or choose the ABAP package

Use the package assigned by your instructor.

Recommended workshop package:

ZCOURSE_GIT_###

If you create a package, place it under the package/superpackage required by the training environment and assign the requested transport when prompted.

Record:

Package used:

---

Part 4 — Create the lab class

Create:

ZCL_GIT_LAB_###

Description:

Git Workshop Lab

Implement:

CLASS zcl_git_lab_### DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

ENDCLASS.


CLASS zcl_git_lab_### IMPLEMENTATION.

  METHOD if_oo_adt_classrun~main.

    out->write( 'Git lab - initial version' ).

  ENDMETHOD.

ENDCLASS.

Replace ###.

Run:

Ctrl + F2
Ctrl + F3
F9

Record the output:

________________________________________

---

Part 5 — Confirm a working initial state

Before using Git:

• Syntax check passes.
• Class is active.
• Console run succeeds.
• No passwords/tokens exist in source.

Question:

Why is it useful to create the first commit from a known working state?

Write your answer:

---

Part 6 — Create a GitHub repository

In GitHub, create a new repository.

Suggested name:

abap-cloud-git-lab-###

Use the visibility required by your instructor.

Initialize it with:

README.md

Do not add credentials to the README.

Record:

Repository name:
Visibility: Public / Private

---

Part 7 — Copy the HTTPS URL

In the GitHub repository:

Code
  → HTTPS

Copy the repository URL.

It should be similar to:

https://github.com/<owner>/<repository>.git

Record only the repository URL if your instructor allows it.

Do not append your token to the URL.

---

Part 8 — Prepare GitHub authentication

Use your institution's approved GitHub authentication process.

For a normal personal GitHub HTTPS repository, this may require a personal access token instead of your account password.

Checklist:

• Credential has only the permissions required for the repository.
• Credential is not stored in ABAP source.
• Credential is not committed to GitHub.
• Credential is not copied into this lab document.

Do not write the token below.

Record only:

Authentication method used: ______________________

Examples:

personal access token
organization-approved credential

---

Part 9 — Start the first Stage and Push

In ADT Project Explorer:

1. locate your package;
2. right-click it;
3. choose:

Stage and Push

Supply the Git repository connection information when prompted.

Authenticate using your approved credential.

NOTE

Dialog wording can vary slightly across ADT/backend versions.

Do not paste credentials into ABAP code or commit messages.

---

Part 10 — Inspect the unstaged changes

Before staging anything, inspect what abapGit proposes to export.

Find your class:

ZCL_GIT_LAB_###

Also notice any package/repository metadata included in the initial export.

Answer:

Does one ABAP object necessarily appear as exactly one Git file?

What other kinds of files/metadata do you observe?

---

Part 11 — Stage the first change set

Stage the files/objects required for the initial working version.

Do not intentionally include unrelated objects from another exercise.

Before committing, verify:

• Lab class is included.
• Required package metadata is included.
• No unrelated course work is included unless the instructor requested it.
• No secrets are included.

---

Part 12 — First commit message

Write a meaningful first commit message.

Recommended pattern:

Add initial ABAP Cloud Git lab example

Your commit message:

________________________________________

Question:

Why is your message better than initial or stuff?

---

Part 13 — Commit and push

Complete:

Commit and Push

Wait for the operation to finish.

Record:

Push succeeded: Yes / No

If it failed, use the Companion troubleshooting section before continuing.

---

Part 14 — Inspect GitHub after Commit 1

Open the repository in GitHub.

Confirm:

• A commit exists for the ABAP source.
• Serialized ABAP files are visible.
• README still exists.
• No credential/token appears anywhere.

Record the first commit message exactly:

________________________________________

---

Part 15 — Find .abapgit.xml

Locate:

.abapgit.xml

Do not edit it.

Answer:

What is this file for at a high level?

Why should you not delete it casually?

---

Part 16 — Inspect the source folder

Find the repository folder containing the serialized ABAP objects.

Commonly this is based under a path such as:

/src/

Record:

ABAP serialized source folder/path:

Question:

Does the Git folder structure exactly equal your ABAP package tree/name?

Explain:

---

Part 17 — Identify the class files

Find the files corresponding to:

ZCL_GIT_LAB_###

Record the filenames you can identify:

1.
2.
3.

Not every serializer/version will produce the same number of files.

Question:

Why can a single ABAP repository object have more than one serialized file?

---

Part 18 — Make the second ABAP change

Return to ADT.

Change the implementation to:

METHOD if_oo_adt_classrun~main.

  out->write( 'Git lab - second version' ).
  out->write( 'This line belongs to commit 2' ).

ENDMETHOD.

Run:

Ctrl + F2
Ctrl + F3
F9

Record the new console output:

---

Part 19 — Verify the second working state

Before committing:

• Syntax check passes.
• Class is active.
• Console execution works.
• Change is intentional.
• No secret was added.

---

Part 20 — Stage the second change

Right-click the package:

Stage and Push

Inspect the proposed changes.

This time, your class should be recognizable as:

modified

rather than a completely new object.

Answer:

What changed between the first and second Git states?

---

Part 21 — Stage only the intended change

Stage the class change required for Commit 2.

If unrelated files are listed, do not stage them merely because they appear in the view.

Question:

What is the purpose of staging instead of automatically committing every current change?

---

Part 22 — Second commit message

Choose a message that describes the actual change.

Example:

Update Git lab console output

Your message:

________________________________________

Commit and push.

---

Part 23 — Verify Commit 2 in GitHub

Open GitHub's commit history.

Confirm that the repository now has at least two workshop commits.

Record:

Commit 1:
Commit 2:

---

Part 24 — Inspect the Git diff

Open the second commit's diff.

Find the source changes corresponding to:

Git lab - initial version

changing to:

Git lab - second version

and the new line:

This line belongs to commit 2

Answer:

What does a diff tell a reviewer that a screenshot of the final source does not?

---

Part 25 — Explain the history

Write a two-line history summary:

Commit 1:

Commit 2:

Then answer:

Does Git history show only the current source, or does it preserve earlier committed states as well?

---

Part 26 — Git vs activation

Complete:

Ctrl + F3
  → ______________________________________

Git commit
  → ______________________________________

Then answer:

Can a Git commit activate an ABAP class?

---

Part 27 — Git vs transports

Complete:

Git / abapGit
  → ______________________________________

ABAP transport / gCTS lifecycle
  → ______________________________________

Then answer:

Should GitHub be treated as a replacement for the normal DEV → TEST → PROD lifecycle in SAP BTP ABAP Environment?

Explain:

---

Part 28 — Supported object types

In your own words, explain this statement:

abapGit does not guarantee that every ABAP repository object type can be imported/exported in ABAP Cloud.

Why should a developer check current SAP documentation before relying on abapGit for an unfamiliar artifact type?

---

Part 29 — Import workflow reasoning

Do not clone the repository into another package in the same system for this required lab.

Instead, put these steps in the correct order:

A. Select branch and target package
B. Open abapGit Repositories view
C. Activate imported objects
D. Choose Clone
E. Enter repository URL
F. Select transport request and finish

Your order:

1.
2.
3.
4.
5.
6.

---

Part 30 — Why no same-system clone?

Answer:

Why could cloning your repository into another package in the same ABAP system fail or create conflicts?

Use the phrase:

system-wide ABAP object names

in your answer.

---

Part 31 — Imported-object activation

Imagine you clone an application into a different ABAP system.

It contains:

CDS entities
ABAP classes
Service Definition
Service Binding

Explain why the imported objects may need activation after import.

Which should conceptually be activated first?

Service Definition
or
Service Binding

Answer:

________________________________________

---

Part 32 — GitHub security check

Inspect your repository one final time.

Confirm:

• No token appears in source.
• No password appears in source.
• No credentials appear in README.
• No secret appears in commit messages.

If a secret appears anywhere, stop and revoke/rotate it before continuing.

---

Part 33 — Repository quality check

Review your GitHub repository.

A good submission should have:

README
.abapgit.xml
serialized ABAP files
meaningful commit history
clear diff between commit 1 and commit 2

It should not contain:

credentials
random unrelated course objects
meaningless commit spam

---

Part 34 — Professional commit exercise

Imagine you are later building a RAP application.

Put these changes into a sensible commit sequence:

Add persistence table
Add root CDS view
Add managed behavior
Add service projection
Expose OData service

Write five commit messages:

1.
2.
3.
4.
5.

Do not use the word:

update

by itself as a commit message.

---

Part 35 — Final reasoning questions

Answer in your own words.

1. What is the difference between Git and GitHub?

2. Where does ABAP source live while you edit it in ADT?

3. What role does abapGit play?

4. What does staging mean?

5. What does a commit represent?

6. What does push do?

7. What is .abapgit.xml?

8. Why can one ABAP class create several Git files?

9. Why should credentials never be committed?

10. Why does Git not replace ABAP activation?

11. Why does abapGit not replace the normal SAP transport lifecycle?

12. Why may imported objects require multiple activation passes?

13. Why is a meaningful commit message useful to another developer?

14. Why did this lab use two commits rather than one final upload?

15. When would importing/cloning this repository into another ABAP development system be useful?

---

Optional challenge 1 — Add a second ABAP object

Create another small object in the same package, for example:

ZCL_GIT_HELPER_###

Make it a coherent addition to the lab.

Stage and commit it separately with a meaningful message.

Then inspect how its serialization differs from the first class.

---

Optional challenge 2 — Add project documentation

Edit the GitHub repository README using the GitHub interface or an instructor-approved Git workflow.

Document:

Workshop purpose
ABAP Cloud requirement
Package naming
How ABAP source is pushed through abapGit

Do not put ABAP credentials or tenant secrets in the README.

Question:

Why can README documentation live in the Git repository even though it is not an ABAP repository object?

---

Optional challenge 3 — Independent import in another system

Complete this challenge only if you have access to a different ABAP Cloud development system and instructor permission.

Use:

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

Choose the clone action.

Provide:

repository URL
branch
target package
transport request

After import:

inspect import log
activate objects
resolve dependencies
run the console class

Do not complete this challenge by importing duplicate object names into the same ABAP system.

---

Evidence checklist

Your instructor may ask you to demonstrate or submit evidence of the following.

Do not include authentication credentials in any evidence.

• GitHub repository exists.
• Commit 1 is visible.
• Commit 2 is visible.
• Commit messages are meaningful.
• Serialized ABAP class files are visible.
• .abapgit.xml is visible.
• Commit 2 diff shows the intended source change.
• Final ABAP class is active and runs in ADT.
• No credentials are visible.

---

Submission checklist

• abapGit Repositories view is available.
• Lab package is identified.
• ZCL_GIT_LAB_### exists.
• Initial version activates and runs.
• GitHub repository is created.
• HTTPS repository URL is used.
• Secure authentication method is used.
• First change is staged deliberately.
• Commit 1 has a meaningful message.
• Commit 1 is pushed successfully.
• .abapgit.xml has been inspected.
• Serialized class files have been inspected.
• Second ABAP change activates and runs.
• Second change is staged deliberately.
• Commit 2 has a meaningful message.
• Commit 2 is pushed successfully.
• GitHub history has been inspected.
• Commit diff has been inspected.
• Git vs activation is explained.
• Git vs transport lifecycle is explained.
• Supported object-type limitation is explained.
• Import workflow is understood.
• Same-system duplicate-name risk is explained.
• No secrets are committed.
• Final reasoning questions are answered.

---

Useful ADT actions

Action	Shortcut / menu
Open ABAP Development Object	Ctrl + Shift + A
Syntax check	Ctrl + F2
Activate	Ctrl + F3
Run console class	F9
Open abapGit view	Window → Show View → Other... → ABAP → abapGit Repositories
Export workflow	package context menu → Stage and Push
Install plug-in	Help → Install New Software...

---

Lab outcome

When you finish, you should be able to explain and perform this workflow without treating ABAP Cloud like a normal local Git folder:

ABAP object in ADT
      ↓
active ABAP repository state
      ↓
abapGit staging
      ↓
Git commit
      ↓
GitHub push
      ↓
Git history + diff

You should also be able to state clearly:

GitHub records and shares serialized ABAP source history; it does not replace ABAP activation or SAP's controlled system transport lifecycle.

---

Next step

Open the workshop companion →