Skip to Content
Author's profile photo Jörg Krause

Branching in ABAP?

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?

Assigned Tags

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

      Seems like quite a lot of trouble for using branches. I guess the SAP way would be to have a dedicated SAP system for each branch.

      abapGit also had a discussion on multiple branches withing one SAP system you might be interested in:

      Author's profile photo Jörg Krause
      Jörg Krause
      Blog 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...

      Author's profile photo Christian Drumm
      Christian 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.



      Author's profile photo Paul Hardy
      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





      Author's profile photo Wouter Peeters
      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?

      Author's profile photo Robert Forster
      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.




      Author's profile photo Jörg Krause
      Jörg Krause
      Blog 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.



      Author's profile photo Manish Sethia
      Manish Sethia


      I would like to understand how did you handle user-exits and BADI's situation with this if you encounter that.




      Author's profile photo Jörg Krause
      Jörg Krause
      Blog Post Author

      In fact, we fork only when necessary, User exits and BADIs are rarely in danger of multi-issue conflicts.

      However, we have a procedure for user exits:

      • create a user parameter for the branch number (ZBRANCH)
      • at the entry include of the user exit, implement a case structure
      *** include ZXEXAMPLE
      get parameter id 'ZBRANCH' field lv_branch.
      case lv_branch.
        when '001'.
           include zxexample_________001 if found.
        when others.
           include zxexample.

      Before forking, adjust the main include as above and release it to prod in order to not block it for further forking. The "if found" addition makes sure there are no problems in prod because of the missing branch sources.

      Author's profile photo Michal Szczerbowski
      Michal Szczerbowski


      We have a 4 system chain, the extra system is a 'maintenance' second development system - it is used only for urgent fixes (because it's next to production) or when a project is locking the traditional chain. Later a change done in Maint has to be re-done in dev and transported properly thru the chain to maintain consistency.

      Dev - QA - Maint - Prod

      It does not solve the queue or CR order, so here we bundled CR in packs, with a delivery a few times a year.


      Author's profile photo Tobias Topyla
      Tobias Topyla

      Hi together! I am really wondering why there is a reason that the individual developers block each other!


      A Workbench transport request should not be kept open for weeks. It makes more sense to release it as soon as a change is implemented. We work like that in a group of around ten ABAP developers without any significant conflicts. Daily scrum meetings established a high level of communication – furthermore we try to complete every task within less than 2 to 3 weeks, maximum of 4 weeks (monthly Agile Sprints).


      What’s about trying to isolate the development objects e.g. using the Model-View-Controller concept to avoid monolithic blocks of ABAP code?

      It makes also sense to utilize ABAP OO and work with the Superclass concept such aus redefining only individual methods where needed. That of course means that you will need to go away from a single REPORT listing with hundreds of lines of code.


      Best regards

      Tobias Topyla

      <do not include phone number>

      Author's profile photo Jörg Krause
      Jörg Krause
      Blog Post Author

      Often, testing of new features takes more than one week and further bug fixes are to be implemented and tested again. Until we have no OK from the testers to go live, we keep the change requests open in development to avoid overdriving by new implementations. For tests, the objects are brought with copy transports to our test system (we have only one).

      In our system, we have some huge home-brewed addons that consist of  up to hundreds of classes, reports, front end programs and so on. Some central classes have a very long where-used list. They are used by many international subsidiaries and we always got a long list of requests for them. We tried to bundle them and begin developing, but as soon as we began, hot fixing was blocked by the current change request.

      For now we are going on using the branching approach for two months. It's improving constantly and it seems to be working fine for us.

      Author's profile photo Former Member
      Former Member

      Development of new features and maintenance of existing code will always collide.

      Therefore we are using 5 System landscape - separate branches for maintenance and new development.

      Release DEV -> Release TEST \
      /|\                           PROD
      Maint.  DEV -> Maint.  TEST /

      Scope and duration of each release is agreed trough all departments.

      Merging of error corrections into new release  partially can be automated with Correction work bench-SCWB.


      No conflicts on transport requests, each error correction is properly tested, new development is properly tested, production system is stable between releases.


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




      Author's profile photo Jörg Krause
      Jörg Krause
      Blog Post Author

      Intreresting, so the orig system of a dev object may differ in your prod system? What, if both a correction in Maint. and a new feature in Release are in the import queue of PROD? Isn't it dangerous to have two systems that can send developments to PROD?

      Author's profile photo Julian Phillips
      Julian Phillips

      SAP provides Charm (on solution manager) for managing this kind of dual track landscape. If you make a change in the application management line, then the tool directs you to make a retrofit into the AD line. The retrofit can be automatic if not application development changes have been made, or it can be more like a SPAU change, if there are conflicts. We have 2 development teams, one AM one AD, and when there are retrofit conflicts it is important that our devs communicate with each other. This process usually works fairly smoothly.


      Author's profile photo Julian Phillips
      Julian Phillips

      The problems we have are that we need multiple projects to go live in the AD line in any one release, then sometimes one project may be delated where the other needs to go live as planned, and then you need multiple working versions of both solutions, and that is where your branching suggestion may be appropriate as far as I can see. There are other alternatives though. For instance using development packages just like SAP do, and then activating the packages or deactivating them. The packages can be used for all types of development as they are tightly integrated into the standard solution, they work with global classes, BADIS, and the enhancement framework, but working with them can be complex.


      Author's profile photo Former Member
      Former Member

      Intersting approach, but sound like (a way) too much work for me...


      Author's profile photo Former Member
      Former Member

      Hi All,


      In my opinion Jörg's approach is fantastic -it comes at cost of copying objects, but it helps to keep the system landscape lean.

      The alternative is to add more development systems to the landscape as Raitis' propossal, but objects should be kept in sync in both systems, otherwise would be a chaos.

      ABAP Git is a good approach but I assume it does not solve the blocking-users problem, does it?


      As Tobias pointed out, why users are blocking each other? Analysing this question might help to generate more ideas -here is mine: assign the spectrum of custom objects between developers, so each of them are responsible of a set of objects e.g.: as a developer I am responsible of 10 Z packages, maintain those and in case someone wants to operate, I should follow up, confirm, etc..

      To complete this idea, these assignments should rotate every X months (in case someone leave the company or needs a backup).

      Important requirement is that the communication between developers must be fluent, and the assigned objects visible (whiteboard, Trello...).