Re: Best practices for working with GIT

Hello Richard

Thank you for your extensive answer! I'll respond to your comments inline

## I will start out with: It all depends on how MUCH you want your workflows to change.

That depends on who you ask... Some of my colleagues are quite conservative on this topic, to put it mildly. We'll need a migration path towards (most probably) Git to get to the desired outcome. The desired outcome is determined along the line of efficiency.


## 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.

I read about your product, that's surely on our research list

## 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.

I think it best for our organization to keep using source files and members

## 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.

I'm suspecting you of a tiny little vendor bias 🙂

## 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.

We thought about this, but were discussing how to get sources from standard application libraries (or directories) into the customization layer via the Git interface. I'm a newbie to Git myself as well, but as far as I understand repos are not interconnected or stacked in a way that libraries are in a library list. Is Git capable of doing this or would that require two actions (copy member and add member to the Git repo)

## 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

We don't use personal libraries at this moment, but got to think that that may become necessary. If not, I would prefer not to (just thinking about the learning curve)

## 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.

I would rather not combine them and keep cutomized sources apart from the standard layer

## 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.

We tried to pick somes sources out of several thousands of members to select add them to the git repo. I was very slow, just to pick the source members in the first place. I that that would be a very common task for colleagues working on customization. It's not the main problem for now.

## 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.

We prefer tot keep source files intact as well

## 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.

I think it's worth having a further chat about that

## 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.

Of course no vendor bias involved...

## Not sure if this helps, but I provided my two cents as promised. You will need more discussion.

Yes, it has been very helpful, thanks!

## Send me an email not if you want me to send you an overview presentation link.

We'll get in touch

Kind regards,

Martijn van Breden