In my company, we are running SAP ERP since the early nineties and the system is full of self-made add-ons that are maintained by a team of abap developers. The traffic of request for improvements or error corrections is high and we often run into blocking conflicts for repo objects.This made me think of setting up a procedure that allows us to work on different features of one program independently like “normal” programmers can do using version control software.

So we started branching in ABAP.

Our approach is yet new and immature, and that’s why I’d like to discuss it here. I appreciate any kind of participation!

The approach

  1. Determine a 3 digit number to identify the branch. We therefore have a central tabular document where all branches are put in.
  2. Make a copy of the repo object and include the branch number in the name of the copy. We do it by filling the original name with underscores and using the last three chars for the branch number.
    So a program
    will be copied to
    ZP_SOME_PROGRAM______001 for branch 001
  3. For global classes, it can be very annoying making a copy, because every usage of the class has to be redefined then changing the reference type of the variable. Therefore, you must copy the user of the class and follow that chain until the main program. This can lead to an explosion of needed copies for one branch. Therefore, we use subclasses for the branches. Then, only the code where a class is instantiated has to be forked whilst the other utilisers can go on with the super class type.
  4. As a consequence of the item above, classes should not use private attributes and methods, for they can not be accessed in a sub class. So step by step we are transforming our classes changing private objects to protected.
  5. When a new feature has been approved, the branch is merged with the master branch (the original objects) using split screen editor (for sources) to apply all changes for the feature of the branch. For other objects like screens and gui status the merge has to be done manually.
  6. For hot fixes, the master branch is changed directly. Hot fixes should go live shortly so the period where the master branch is blocked by a change request remains as small as possible.

I hope you got the idea. What do you think of it?

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Jörg Krause Post author

      Thanks for the link! What they discuss there is similar to our approach.

      Obviously for us it’s not possible to use different systems. A branch is a temporary thing in our workflow. We started two weeks ago with branching and already have 8 branches on the dev system. To us the question was: accepting all the “trouble” for the sake of being able to fork, or accepting all the trouble we have with concurring requests that block each other and make hot fixes impossible. At the moment, the first alternative seems to be the better. But we are still in pilote phase…

  1. Christian Dr. Drumm

    Hi Jörg,

    for me it seems you are going through all this trouble not to fork but to have different forks active at one in the same development or QA system. This is something I would never want to do.

    IMO a fork would be to have one active version (current development) and an old version that might need to be maintained. For this scenario there is no need to have both versions active in the system. Instead you could use ABAPGit to create a branch (stored in the git server) and always only checkout (and transport) the branch you are currently working on.

    Of cause, this does not solve the situation where multiple developers need to work on the different branches at once. For this situation IMO the “Ethan setup” is the most viable approach. However, for it to work you would have to give an own development machine to all developers and would have to need the necessary automation in place.



  2. Paul Hardy

    My understanding is that there is something called “ABAP GIT” which has been around for a while now, to provide the sort of functionality you are developing yourself.


    There might even be several versions of ABAP GIT here is one:-



    SAP Mentor Graham Robinson is always on about trying to get me to use ABAP GIT – he gives speeches about this at SAP events – and I am convinced.


    His speech at a forthcoming Australian SAP event is descried thus:-


    “See how ABAP developers can work with Git-based version control systems. See how to install and use abapGit in your own ABAP development projects starting right now.

    The use of distributed version control systems like Git has transformed the daily workflow of developers everywhere – but ABAP’ers have remained inside the SAP walled garden. Initiatives like abapGit break down these walls and allow ABAP developers to implement the latest development workflows, change management techniques, code sharing, code recovery, change tracking, branching, merging, etc.

    We will discuss how abapGit can enhance and complement the traditional ABAP developer and change control process. And it is all OpenSource!”


    It is ironic that at any given time, many ABAP developers are working to create the same thing, most notably a way t export data to EXCEL despite ABAP2XLSX having existed for some years now.


    It is a communication problem!


    Cheersy Cheers





    1. Wouter Peeters

      I’ve read about abapGIT several times, but, what about dependencies with DDIC? I think 50% of my code will have a dependency with DDIC changes. Anyone?

  3. Robert Forster


    let my say one thing about “normal” programmers vs. ABAP.

    ABAP is using a central version control system.

    Other languages using (like your example) as well central and/or decentral version control systems.

    If you check out all the literature about GIT and decentral versioning this could be a big challenge as well.

    I think you also will get trouble finding people with experience in ABAP and decentral versioning.

    Your problems sounds severe, but IMO there are some techniques (interfaces, BAdI’s…) and programming philosophies (release early, release often;  AGILE…) which address these problems.




  4. Jörg Krause Post author

    Thanks to all for sharing thoughts so far.

    Even though the comments are all quite critical, we begin to have benefits from using this kind of branching for now. The advantage is that we can work isolated on several new features or bug fixes for the same set of programs and put them also to test. We simply tell our testing personnel to use the transaction of the branch. We even began branching on smartforms.

    There are still few experiences on merging because until now, no commitment arrived which would us make merge a branch with the master. I’ll come back and tell you later on about it.




Leave a Reply