Versioning your local objects using abapgit

Leveraging the power of git in SAP can be difficult since development is usually done by multiple developers on the same system. Unless you manage to get your developers their own systems, key concepts like branches will be next to useless because while you’re pushing the results into something meant for distributed development, you’re still doing centralized development.

“Hell is other people on your system” (Jean-Paul Sartre)

However, even on a shared system, you have one place where other people generally won’t bother you – your local objects. You can consider this your single-developer system where you can put prototypes or reusable code.

But since local objects are never transported, you no longer have them if you switch systems and if something were to happen to them, you can’t recover them easily. We can get around both of these issues by versioning them using git.

I’m going to assume abapgit is already set up on your system. It is not difficult, the simplest way involves copy-pasting a report.

From what I’ve seen, most people use the organization structure

my_username->literally_everything

for their local objects and don’t structure them further. This is equivalent to putting all your files on the desktop. Which I do, but who’s not a hypocrite these days.

You will need to create at least one top level package for this. Much better!

Your local objects are stored in the package $TMP, but since you don’t want to version everyone’s code, create a subpackage of $TMP. Name it whatever you like, just remember that local package names start with $.

You can also have multiple root packages/repositories, this depends on your use cases. I don’t know what code you have in there, that’s why I’m trying to get you to share it! You just need to:

Create a package

Create a Github repository:

Don’t forget the readme checkbox.

Open ZABAPGIT and click the +Online button

Now you will learn how to add some folder structure to your repo. Abapgit will let you version one top-level package per repository. Any subpackages will be converted to folders based on the folder logic.

There are two options:

• PREFIX – the child packages must begin with the parent package name. For example, $ZFH_PROTOTYPES is a valid subpackage of $ZFH according to prefix logic. This will create a folder named prototypes in the repository. Note that prefix logic won’t work correctly if you don’t follow the convention.
• FULL – folders will be named like packages.

You can create the subpackages and also change the folder naming convention at any time.

Now just add your objects and remember to commit updates every now and then.

=

At the very least, you get a backup and the ability to import your local objects to a different system. You also have a place where you can experiment with branching, pulling or resetting code to previous versions, which you might be afraid to do with your productive code.