I will start out with: It all depends on how MUCH you want your workflows to change.
I'll add two cents as this entire thing could take hours or days to discuss.
For the record there are commercial tools to help with much of this, including my iForGit product which is mainly a green screen, RDI, VS Code git component that allows you to keep your source files intact as well as IFS files for your web development.
Initial developer learning curve can be zero if you agree with the concept of not getting rid of your source files. If you flip to git-centric development from the PC for classic RPG/CL workflows, life gets interesting.
On to my thoughts:
1) What would be the best practices to run this situation under Git source control in RDi (with eGit).
-Don't use eGit unless you are planning to have a complicated workflow.
2) What would be a decent structure for the git repos? A branch per library and/or directory or something else?
-I tend to have each library in its own repository.
-I would imagine custom libraries should also have their own repos.
-Similar with IFS/PC based assets.
-Without visualizing the entire structure it's hard to tell for sure.
3) How can (and should) we work with personal developer libraries and directories?
-You can still do personal developer libraries and directories if that makes sense, but you have two app project types: Classic IBMi Source Dev and Project Based IFS/PC style development
4) Should we i.e. be combining standard and customized source to a single customer library/directory and would this affect performance and memory usage (since the number of instances of a program increases)
-You could combine your libraries, but this could be messy if you have the same source member in multiple custom libraries.
5)How can we improve the initial load time for source members in RDI
-Not sure what you mean by this ? RDI is always slow to load source members from a source PF in my experience.
6)Can we do an automatic push (to a source member) and compile on save. Can we influence the target library for the compile?
-Once you establish a desired workflow via whatever tool you choose this can possibly be accomplished, but every vendor has a thought process that may differ.
-I focus on keeping source files intact. Other vendors are starting to flip you to the git-first development method which can actually add steps if not done right and will potentially frustrate developers.
7) What is the best practice to incorporate our custom compile command with eGit in RDI?
-RDI actions most likely ? That's how I interface custom commands including the commands as part of my iForGit product.
8) What is the preferred way of interaction between i Projects and eGit?
-Just don't use iProjects 😊
I looked at them once and it just felt complex.
Not sure if this helps, but I provided my two cents as promised. You will need more discussion.
iForGit web site:
https://www.iforgit.com
Send me an email not if you want me to send you an overview presentation link.
Regards,
Richard Schoen
Web:
http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
-----------------------------
message: 2
date: Thu, 18 Sep 2025 08:56:39 +0000
from: Martijn van Breden <m.vanbreden@xxxxxxxxxxxxxxxxxxxxxxxxxx>
subject: Best practices for working with GIT
Hi all,
We're currently investigating how we can implement git (via eGit) in our workflow. There are so many possibilities that we're getting a bit lost.
Just to elaborate on our current situation
We are an ISV with a homegrown browser based software application integrating ERP and finance and some production, service and warehouse management applications, so it's pretty broad. We have customers ranging in size from a handful of users to several hundreds. For most of our customers we have customized code to meet their specific goals. Some of them have so much customization on older versions that they will probably not move to our newest version in the near future.
Our code resides in several libraries in a library list that is established when the user logs on. Besides the libraries we have several directories containing the front end GUI for the application. Via a directorylist similar to the LIBL we can add customization and DTAP layers to the directory list. The directory list is scanned for scripts just as the libary list is used to determine which object should be used.
At a glance the LIBL looks basically like this.
CUSTPGMDEV - developtment customized application programs CUSTSRVDEV - developtment customized service programs [CUSTPGMTST - test customized application programs] [CUSTSRVTST - test customized service programs] [CUSTPGMACC - acceptance customized application programs] [CUSTSRVACC - acceptance customized service programs] CUSTPGMPRD - customized application programs CUSTSRVPRD - customized service programs STDPGM - standard application programs STDSRV - standard service programs STDFUNC - standard functions (never customized) CUSTDATA - customer data
Customization libraries only contain sources and objects that are modified or supplemental to the standard application, so it is a subset of the application. Not in all cases both the test and acceptance layers are present.
For directories we have a similar structure with a standard directory and customization directories. The substructures of all directories are equal.
/maindir/custgui
/maindir/stdgui
the customization layer is again modiefied or supplemental to the standard layer.
On our cloud partitions we have several dozens of cutomers working with the same standard base libraries and directories each with their own customization layer on top of them.
Th number of RPG sources in the STDPGM is well over 8000 to give an indication of the size of the application.
My questions are:
1 What would be the best practices to run this situation under Git source control in RDi (with eGit).
2 What would be a decent structure for the git repos? A branch per library and/or directory or something else?
3 How can (and should) we work with personal developer libraries and directories?
4 Should we i.e. be combining standard and customized source to a single customer library/directory and would this affect performance and memory usage (since the number of instances of a program increases)
5 How can we improve the initial load time for source members in RDI
6 Can we do an automatic push (to a source member) and compile on save. Can we influence the target library for the compile?
7 What is the best practice to incorporate our custom compile command with eGit in RDI?
8 What is the preferred way of interaction between i Projects and eGit?
I hope some of you have far more experience than we have and can help us further on this topic.
Kind regards,
Martijn van Breden
lead software architect
midrange.com
