Project4i 1.0: Git comes to IBM i projects

On 30 October 2026 Project4i 1.0.0 came out, the first general-availability release according to the changelog, and with it Git Mode: the source of an IBM i project lives in a Git repository, is edited locally and is promoted from a commit. 1.1.0 followed on 6 November. Both are on the Visual Studio Marketplace and on Open VSX.

The extension 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 guide's own words, Git becomes the way source is versioned and shared, and Project4i remains the way software reaches production.

The central repository lives on the IFS of your own IBM i, and only the project's files reach the PC. A Git project is always a shared project.

A merge never writes to production

A merge at most triggers a deploy to DEV. From there the usual promote engine takes over: pre-promote backup, authority policies, a check on data files, the deploy register and rollback. The guide gives two reasons:

• Segregation of duties. If a merge wrote to production, anyone allowed to merge would 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.

Example: one change from start to finish

The example is the one in the user guide: ticket and program are invented, the action names are the product's.

Ticket CHG-1234 asks to add a discount to program ORD010R in QRPGLESRC.

1. Get the latest shared version, then Start a change named CHG-1234: you work on your own branch.
2. Edit src/QRPGLESRC/ORD010R.RPGLE on the PC.
3. Git Compile (Ctrl+Alt+C): the file is uploaded to the project's Git library and compiled with the project's compile templates. Errors appear in the Problems view, on the local file.
4. Save your work into a version, that is a commit, with the ticket in the message; then Publish your work sends it to the central repository.
5. Finish the change merges the branch into the shared version, after code review if the project requires it. If a colleague touched the same lines, Git stops on the conflict.
6. Publish your change into the shared library, promotion DEV, UAT, PROD as always, and finally Verify production against Git, which tags the version running in production.

For a production incident there is Start an urgent fix from production, which starts from the version tagged in production rather than from work in progress. Every action also shows the equivalent git command.

Git Compile and physical files

Git Compile uses the library and job description set in the Git section of the project properties; if they are not set, those of the DEV environment. On physical and logical files it asks for a confirmation warning that the records will be lost, and does not recompile at all when dependent logical files exist. All checks run before anything is written on the system.

Fixed-format source

• One folder per source file: PGM1 in QRPGLESRC and PGM1 in QCLLESRC stay two files.
• The member lock becomes a warning, and by design there is no blocking level. The warning stays because, according to the guide, on RPG III, RPG IV and DDS an automatic merge can produce lines that are syntactically valid with the fields in the wrong columns.
• Over-long lines are stopped before the commit, with the line number, because IBM i would truncate them without failing the command.
• Conflict markers (<<<<<<<, =======, >>>>>>>) block saving and sending to the library. They are recognised only in column 1, so a fixed-format RPG or DDS line is never taken for a conflict marker.

Personal development libraries

Two developers on two branches compiling into the same library overwrite each other while believing they are isolated. The development library can be one per project, the default, or one per developer. A name longer than ten characters is refused and never shortened: shortened, MARIOROSSI and MARIOROSSETTI would land on the same library.

What to prepare

The administrator, once, from Control Panel → Git Mode: creates the central repository, choosing the owning group and the initial branch; loads into it the source currently in production, so history starts from what actually runs; protects it so that it is only updated through Project4i.

Each developer, once per project: the SSH key, the link to the repository, the working copy, and a personal library if needed.

You need git on the IBM i and an SSH client. How to install git from IBM's RPM packages is in RPG source in Git. The guide states no minimum git version: the Setup Health Check reports a version that is "too old" without saying which.

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

Existing projects

The mode is chosen per project, and a project with no explicit mode stays traditional. An existing shared project can be moved to Git with Convert this project to Git Mode: nothing changes until you confirm, and projects that are not converted work as before.

Which versions it works on

It installs alongside Code for IBM i, in VS Code or in IBM Bob.

When it pays off

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

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