Re: Best practices for working with GIT

I know just enough about Git to be dangerous. I've always had a vendor supplied SCM (Source Control Management) product, which not only did source control but also did deployment. Git will not do your deployment (to the best of my knowledge) and that's something to consider.

There is probably open source software that could be configured to do your deployment. But I think you should seriously look at a vendor package.

Sam

-----------------------------

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