Introduction > Git Editing Workflows

Listed below are some example workflow use-case flow scenarios for editing source and version controlling with iForGit.

If you have a use case such as hooking into a custom source control system or augmenting an existing source control system, make sure to reach out to discuss.

Automatic Passive Versioning of Source Changes Hourly or Daily (Background Versioning/Backup of Existing Source To Git On-The-Fly)

•Set up a scheduled job to run the LIBSRCEXP command with a start date of *YESTERDAY, *LAST7, *LAST30 etc to capture changes automatically from source files based on source change dates.

•Schedule at least once per day, but 2 or 3 times per day will insure you're getting more frequent change captures.

•Optional - Set up your repositories to be connected to a remote Git server such as: Github, Gitlab, Bitbucket, Bonobo Git Server (Windows) or other Git remote server or on-premise hosting platform. A remote repository is NOT needed to start versioning your source. All source can live in the IFS based git repository if desired.

This is the easiest way for traditional IBM i development shops to get started editing and versioning source after initially exporting library to git repository using LIBSRCEXP without developers needing to do anything new. We call it passive version control.

This option assumes you have developers who may not be interested in learning source version control, so you can implement source control passively for your initial rollout until you are ready to train your developers. iForGit requires anywhere from NO training to very minimal training on how to use the GE and GI PDM options. Any developer can be trained on the basics in less than an hour.

Simple Version Control for Editing and Versioning Source Members (Version/Backup Existing Source To Git On-The-Fly)

•Use the GE PDM option or directly call SRCTOGIT to commit your changes to your git repository before editing. This insures the git repository is current for this source member. (Optional)

•Edit a source member via SEU, RDI or VS Code and save your changes when done. Nothing new here. Source member locking works as always.

•Use the GE PDM option or directly call SRCTOGIT to commit your changes to your git repository after editing.

This is the easiest way for traditional IBM i development shops to get started editing and versioning source after initially exporting library to git repository using LIBSRCEXP. Developers simply use the GE or GI PDM options to version source members.

This option requires a conscious effort to commit or pull source members, but is integrated to PDM as a User option via the GE and GI options so very easy to learn.

Simple Version Control for Rdi Users Editing Regular Source Members from Source Files

•Use RDi Remote System Explorer to edit and save source member.

•Create an RDi user action to call SRCTOGIT to commit source changes or you can use the WRKMBRPDM GE option to call SRCTOGIT.

•Create an RDi user action to call SRCFRMGIT to get most recent source version from Git repository or you can use the WRKMBRPDM GI option to call SRCFRMGIT.

This option requires a conscious effort to commit or pull source members, but is integrated to RDi as a User Action.

Simple Version Control for VS Code Users Editing Regular Source Members from Source Files

•Use VS Code for IBM i plugin to edit and save source member to IBM i.

•Create a VS Code member action to call SRCTOGIT to commit source changes or you can use the WRKMBRPDM GE option to call SRCTOGIT.

•Create a VS Code member action to call SRCFRMGIT to get most recent source version from Git repository or you can use the WRKMBRPDM GI option to call SRCFRMGIT.

This option requires a conscious effort to commit or pull source members, but is integrated to VS Code as a member action.

Simple Version Control for Notepad++, VS Code and Other Editor Users Editing from the IFS

•Work with your source in the IFS local repository or check out your own local PC copy and edit source members.

•Commit source members from your PC to a local IFS repository or from your PC to a remote repository and then do a pull into the IFS for the source member with your Git client.

•Or simply use the GITCMD CL command with a pull option to pull changes from a remote repository to the IFS for editing.

•Or simply use the WRKMBRPDM GE option to call SRCFRMGIT to pull the member from the local or remote repository to the IFS and to a source member

Note:When using Notepad++, VS Code or other editors you may need to schedule some custom training to come up with a Git workflow that meets your team's needs.

Versioning an IFS Based Git Project Repository

•Work with your source in the IFS local repository or check out your own local PC copy and edit source members.

•Commit source members from your PC to a local IFS repository or from your PC to a remote repository and then do a pull into the IFS for the source member with your Git client.

•When ready to commit repository changes you can use the git CLI command from a PASE/SSH command line if desired.( If you're comfy with the cli you don't really need to use iForGit commands for pure IFS based projects.)

•You can optionally use the GITCMD CL command if desired to perform up to 10 git commands in sequence. Ex: add ., commit -m "My Commit", pull, push (Can be job scheduled in a traditional IBM i job)

•You can use the IFSCOMMIT CL command if desired for to perform the git add and commit actions on a local IFS repository. This command does not do a push or pull. That would need to be done separately if needed by GITCMD perhaps. (Can be job scheduled in a traditional IBM i job)

This option is a good way to commit changes for an IFS project quickly without having to run a bunch of manual git CLI commands for versioning an IFS based project. (PHP, Python, Node, Java,etc)