Skip to Content
Technical Articles
Author's profile photo Conrad Donau

Using Git “one-way” with SAP Cloud Application Studio (C4C)

How you organize your coding as a team is one of the most important things to consider before you start developing. Most programming environments support you with a powerful built-in repository or you can use integrations with third party repositories to synch and modify code (e.g. git).

The feature set of such tools includes functions like checking out code, clone developments to work in parallel, merge coding, and so on. You can track changes, make code reviews and set-up a continous integration pipeline to deploy your coding in a standardized and automated way.

Unfortunately SAP Cloud Application Studio comes with a very poor version control system (gently speaking). In this blog post I will describe how we achieved a one-way integration (no pull) with git and why this is still very beneficial and helps us a lot to get cleaner code in our solution.

Version control in SAP Cloud Application Studio

The repository of the SAP Cloud Application Studio supports checking out and checking in of objects like ABSL methods. This is to prevent parallel development on the same object. There is no way to see what changes were made after checking in and no overview about new created objects. If you work in a group (that means more than one developer) it becomes quite hard to track what happens in your solution.

Furthermore if you’re crazy enough (we are!) to work in a 3 system landscape and try to establish some kind of “agile development” or “continous integration” (I put these terms in quotation marks since real CI seems impossible) you will face the problem that once something was assembled it will rest in your solution forever and ever. There is no way of renaming, moving or removing of objects after that (that’s said maybe someday SAP will enable deletion of objects).

With this known restrictions it becomes crucial to have some kind of code control if you start to develop a serious C4C solution because otherwise you have a high chance of messing up your solution with no way back (we did). This is where git comes in.

What is git?

Git is the heaven on earth for developers. It is used to track changes in files (e.g. coding), you can work on different branches of the same coding (e.g. one branch for a bug fix and another one for a certain feature) and assists in merging these branches again. There is even an ABAP integration with the popular ABAPGit framework of Lars Hvam. The principal operations are

  • pull: Download a version of the repository into your local repository
  • commit: Save changes in your local repository
  • push: Upload your local repository

A normal git-workflow is a pull, then many commits and finally a push to synch back your files. For more information just look it up on wikipedia.

The one-way integration in SAP Cloud Application Studio

First things first: Since Cloud Application Studio is always fetching the solution from its own repository it is impossible to do a pull to get your code from git. However the thing you can do is to commit and push your code back into your own repository. This is why we call it the “one-way-integration”.

For normal developers this might be already a no-go and nightmare but with the C4C restrictions mentioned above this actually enables the team to get back control over their code. Before assembling a solution we use git to do code reviews and in particular we’re checking all new objects which were created because this is the last chance to rename or (re)move them.


Set-up (with github)

Of course you can use your own git server but in this case we will be using github:

  1. Create an account on github and create a repository
  2. Remember the git URL of your repository. You can see the URL here:
  3. Install the git client on your computer
  4. Create a “.gitignore” file in your Cloud Application Studio tenant folder (normally ~/Documents/CopernicusIsolatedShell/Projects/<YOUR_TENANT_NAME>)

    Update: Jürgen Tessmann shared with me an extended “.gitignore” file which includes also some Visual studio interanl files:

    ## ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    ## SAP Cloud Appplication Studio
    ## ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    ## Ignore Visual Studio temporary files, build results, and
    ## files generated by popular Visual Studio add-ons.
    ## Version from 23.09.2019 
    ## Get latest from
    # User-specific files
    # Build results
    # Files built by Visual Studio

    This tells git to ignore the lock and session files. Otherwise you might get an error when commiting.

  5. Start git bash
  6. Execute git config
    git config --global "<YOUR_USERNAME>"
    git config --global "<YOUR_EMAIL>"​
  7. Change to your C4C tenant folder
    cd Documents/CopernicusIsolatedShell/Projects/<YOUR_TENANT_FOLDER>/​
  8. Initialize the repository
    git init​
  9. Set your git URL for synch
    git remote add origin<YOUR_REPOSITORY>.git​

Ok, now your ready!

Daily Doing

Now comes the easy part. Everytime you develop something in Cloud Application Studio make a git commit.

git commit -a -m "<SOME_DESCRIPTION>"

When you finished your work or want to synch developments make a push and all your commits will be transferred to github:

git push origin master

In Github you can see the code changes and e.g. create issues when you see something which needs to be adressed with the developer (check the github Tutorials for all available features).


This integration is far from being called a good solution but still it enables us to keep our developments as clean as it is possible within the restrichtions of SAP Cloud Application Studio. Of course we all are dreaming of refactoring capabilities like renaming, moving or deletion but a small step is better than no step.

If you are really thinking about making bigger developments in C4C in a 3 system landscape I really recommend at least considering this method of seperate version control because I assure you that sooner or later you will run into problems of code governance otherwise.

I’m looking forward for comments how you try to keep your ABSL code in shape!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Johannes Schneider
      Johannes Schneider

      Thanks for the guide, I am going to try and set it up aswell.

      Author's profile photo Vincent Vancalbergh
      Vincent Vancalbergh

      This is fine as long as you only have one solution with one tenant. But once you have

      • Multiple solutions in one tenant
      • Multiple customers in one tenant (when you have a real development tenant whose version moves along with PRD)

      You have multiple solutions in the same folder. And a solution is only updated if you open it. Then run into the problem that, if developer 1 changes something in Solution A and commits/pushes this and developer 2 changes something in Solution B and commits and pushes this, the solution A folder in developer 2's push will be the old version without developer 1's change. This creates merge conflicts.

      Each developer then needs to take care to only stage changes to the solution they actually changed.

      We're working on a system to copy the files to a separate folder and have the git repository there.

      Author's profile photo Conrad Donau
      Conrad Donau
      Blog Post Author

      Indeed Vincent Vancalbergh , you are absolutely right. Are you using a specific tool for synching the visual studio folder with your local git folder?

      Author's profile photo Yergali Yertuganov
      Yergali Yertuganov

      @conrad -  First of all thank you for your post on this Critical Topic and Indeed agree with all the comments on limitations of SAP Cloud Application Studio and this proposed solution. We are facing similar issues and trying to maybe use the same approach so I have been doing some tests in Sandbox. I have following few questions if you could comment on:

      1. I see this original post was from 2019 and was wondering 4 years later what is your experience with this approach, did it work, any new lessons learnts?
      2. How did you manage Push only Repository in Github? I mean if lets say Developer A does changes, activate it and then push it to Github DEV branch, then Developer B opens Cloud App Studio and since it does fetch those changes from Cloud Repo it will show those changes, which you cant Push into GitHub without Pull/Fetch first. Alternatively I could Discard those changes, but then I wont have latest state of Cloud App Studio content in my local repository. Or did you guys create Individual Branch for each Developer where they will only Push and manually merge them into Common DEV branch in Github?

      @vincentvancalbergh - I have read your comments too, was wondering what sort of approach are you using? Do you mean for GIT you have separate folder in your local PC, which is not the Cloud App Studio Project folder? But do you copy then manually individual changed files into there?

      @juergen.tessmann - I have tagged you also if you have any comments on the questions above.

      Many thanks to all.