Project4i Git Mode: what changes for your source

Project4i has documented Git Mode, the mode that brings Git into the IBM i projects managed by the extension. The feature is not active yet: the user guide dated 23 September 2026, headed version 0.4.0, describes it as being finalised, and the latest version published on the Marketplace is 0.3.9.

The project as a whole is described in Project4i: what if sources had a project?. This article covers only what changes with Git.

The principle

In the documentation's own terms, Git becomes the way source is versioned and shared, while Project4i remains the way software reaches production.

The repository is hosted on the IFS of your own IBM i. The object that reaches each environment is built from a commit, by the promote engine Project4i already uses today.

The per-project choice

The mode is chosen when the project is created. A project with no explicit mode is traditional, and existing projects stay traditional: there is neither migration nor data conversion. Anyone already using Project4i sees nothing change until they create a Git project.

A merge never writes to production

This is the most significant choice. A merge at most triggers a deploy to DEV; from there the existing engine takes over, with pre-promote backup, authority policies, a check on data files, the deploy register and rollback. The documentation gives two reasons:

• Segregation of duties. If a merge wrote to production, anyone allowed to merge could write to production.
• Git does not compile. A merge produces text. Without the promote engine, a failed compile would leave production with the new source next to the old object, with nothing to flag it.

Fixed-format source

• One folder per source file, as in src/QRPGLESRC/PGM1.RPGLE: a PGM1 in QRPGLESRC and one in QCLLESRC remain two separate files instead of overwriting each other.
• The member lock becomes a warning, and by design there is no blocking level. The warning stays because, according to the documentation, on RPG III, RPG IV and DDS an automatic merge can produce lines that are syntactically valid with the fields in the wrong columns.
• Line length is checked before the commit. A line longer than the member can hold is refused with its line number, because IBM i would truncate it without failing the command.

Personal development libraries

Two developers on two branches compiling into the same library overwrite each other while believing they are isolated. For this reason the development library can be one per project, the default, or one per developer. A name longer than the ten characters IBM i allows is refused and never shortened: shortening it would put two developers with similar names on the same library.

Example: two developers on the same program

Anna and Luca both need to change the same program, PGM1 in QRPGLESRC.

In a traditional project Anna locks the member. Luca sees the lock with the name of whoever holds it and waits for it to be released.

In a Git project with personal libraries:

1. Each works on their own branch, on the local file src/QRPGLESRC/PGM1.RPGLE.
2. Each compiles into their own development library, without touching the other's.
3. Luca gets a warning that Anna is working on the same member. It does not stop him, but it tells him the columns need checking at merge time.
4. At commit, a line that is too long is refused with its number.
5. The merge at most triggers a deploy to DEV. From DEV onwards the pipeline is today's, with backups and approvals.

What the system needs

Git Mode requires git on the IBM i and an SSH client, and treats the SSH key as a requirement. The documentation describes a Setup Health Check that reports a missing git, a version that is too old or a missing SSH client, with a severity that depends on whether Git Mode is actually in use. The minimum git version is not stated.

The guide lists four problems, stated as observed on a real IBM i and handled by the extension:

The second also applies to checks done by hand: a "not found" obtained over a non-interactive SSH connection does not prove that git is missing.

Release status

When it pays off

Git Mode addresses parallel work on the same application. Before adopting it, the question to ask is how many times in recent months someone has had to wait for a locked member: if the answer is hardly ever, traditional mode is enough and costs less.

If waiting is frequent, the benefit is real on two conditions. The first is personal libraries, without which the parallelism is only apparent. The second is a manual check of merges on fixed-column source, which the documentation itself identifies as the point where an error goes unnoticed.