Project4i 1.0: Git entra nei progetti IBM i

Il 30 ottobre 2026 è uscita la 1.0.0 di Project4i, la prima versione definitiva («general availability» nel changelog), e con lei Git Mode: i sorgenti di un progetto IBM i stanno in un repository Git, si modificano in locale e si promuovono da un commit. Il 6 novembre è seguita la 1.1.0. Entrambe sono sul Visual Studio Marketplace e su Open VSX.

L'estensione nel suo insieme è descritta in Project4i: e se i sorgenti avessero un progetto?.

Il principio

Nelle parole della guida, Git diventa il modo in cui il sorgente viene versionato e condiviso, e Project4i resta il modo in cui il software arriva in produzione.

	Modalità tradizionale	Git Mode
Sorgente di riferimento	libreria IBM i	repository Git
Modifica	membro remoto	file locale sul PC
Lavoro in parallelo	blocco del membro, uno alla volta	branch e merge
Promozione	da libreria a libreria	da un commit a una libreria

Il repository centrale sta sull'IFS del proprio IBM i, e sul PC arrivano solo i file del progetto. Un progetto Git è sempre un progetto condiviso.

Un merge non scrive in produzione

Un merge avvia al massimo un deploy verso DEV. Da lì lavora il motore di promozione di sempre: backup prima della promozione, criteri di autorizzazione, controllo sui file dati, registro dei deploy e rollback. La guida dà due motivi:

Separazione dei compiti. Se il merge scrivesse in produzione, chiunque possa fare merge scriverebbe in produzione.
Git non compila. Un merge produce testo; senza il motore di promozione una compilazione fallita lascerebbe in produzione il sorgente nuovo accanto all'oggetto vecchio.

Esempio: una modifica dall'inizio alla fine

L'esempio è quello della guida utente: il ticket e il programma sono inventati, i nomi delle azioni sono quelli del prodotto.

Il ticket CHG-1234 chiede di aggiungere uno sconto al programma ORD010R in QRPGLESRC.

Get the latest shared version, poi Start a change con il nome CHG-1234: si lavora su un branch proprio.
Si modifica src/QRPGLESRC/ORD010R.RPGLE sul PC.
Git Compile (Ctrl+Alt+C): il file viene caricato nella libreria Git del progetto e compilato con i modelli di compilazione del progetto. Gli errori compaiono nella vista Problems, sul file locale.
Save your work into a version, cioè un commit, con il ticket nel messaggio; poi Publish your work lo porta al repository centrale.
Finish the change unisce il branch alla versione condivisa, dopo la revisione del codice se il progetto la richiede. Se un collega ha toccato le stesse righe, Git si ferma sul conflitto.
Publish your change into the shared library, la promozione DEV, UAT, PROD come sempre, e alla fine Verify production against Git, che marca con un tag la versione che gira in produzione.

Per un guasto in produzione c'è Start an urgent fix from production, che parte dalla versione marcata in produzione e non dal lavoro in corso. Ogni azione mostra anche il comando git equivalente.

Git Compile e i file fisici

Git Compile usa la libreria e la descrizione di lavoro indicate nella sezione Git delle proprietà del progetto; se non sono indicate, quelle dell'ambiente DEV. Su file fisici e logici chiede una conferma che avverte che i record andranno persi, e non ricompila affatto se esistono logici dipendenti. I controlli girano tutti prima di scrivere qualcosa sul sistema.

I sorgenti a formato fisso

Una cartella per file sorgente: PGM1 in QRPGLESRC e PGM1 in QCLLESRC restano due file.
Il blocco del membro diventa un avviso, e di proposito non c'è un livello bloccante. L'avviso resta perché, secondo la guida, su RPG III, RPG IV e DDS un merge automatico può produrre righe sintatticamente valide con i campi nelle colonne sbagliate.
Le righe troppo lunghe si fermano prima del commit, col numero di riga, perché IBM i le troncherebbe senza far fallire il comando.
I segni di conflitto (<<<<<<<, =======, >>>>>>>) bloccano salvataggio e invio alla libreria. Sono riconosciuti solo in colonna 1, così una riga RPG o DDS a formato fisso non viene presa per un segno di conflitto.

Le librerie di sviluppo personali

Due sviluppatori su due branch che compilano nella stessa libreria si sovrascrivono credendo di essere isolati. La libreria di sviluppo può essere una per progetto, come avviene di serie, oppure una per sviluppatore. Un nome oltre i dieci caratteri viene rifiutato e mai accorciato: accorciato, MARIOROSSI e MARIOROSSETTI finirebbero sulla stessa libreria.

Che cosa preparare

L'amministratore, una volta, da Control Panel → Git Mode: crea il repository centrale scegliendo il gruppo proprietario e il branch iniziale; ci carica i sorgenti che sono in produzione, così la storia parte da quello che gira davvero; lo protegge perché si aggiorni solo attraverso Project4i.

Ogni sviluppatore, una volta per progetto: la chiave SSH, il collegamento al repository, la copia di lavoro, e se serve la libreria personale.

Servono git sull'IBM i e un client SSH. Come si installa git dai pacchetti RPM di IBM è in I sorgenti RPG in Git. La guida non indica una versione minima di git: il Setup Health Check segnala una versione «troppo vecchia» senza dire quale.

La guida elenca quattro trappole, dichiarate osservate su un IBM i reale e gestite dall'estensione:

Trappola	Che cosa succede
clone riuscito e vuoto	un repository nato su `master` mentre tutti fanno push su `main` dà un clone che esce con codice 0 e non contiene niente
comando presente ma «non trovato»	il login SSH non interattivo può non vedere i programmi di git
password che non arriva	git non passa una password in modo non interattivo: clone e push restano appesi invece di fallire
gruppo che vuol dire tutti	il gruppo primario dell'utente può essere quello di sistema; il gruppo viene chiesto

I progetti che ci sono già

La modalità si sceglie per progetto, e un progetto senza modalità esplicita resta tradizionale. Un progetto condiviso esistente si può portare in Git con Convert this project to Git Mode: fino alla conferma non cambia niente, e i progetti non convertiti funzionano come prima.

Su quali versioni funziona

Versione	Data	Che cosa porta
0.3.9	pubblicata il 1° settembre 2026	ultima senza Git Mode, ultima con licenza MIT
1.0.0	30 ottobre 2026	Git Mode, Git Compile, licenza freeware
1.1.0	6 novembre 2026	comandi CL prima e dopo la promozione; corretta la promozione dei programmi SQL RPG e SQL COBOL OPM

Si installa accanto a Code for IBM i, in VS Code o in IBM Bob.

Quando conviene

Git Mode risolve il lavoro in parallelo sulla stessa applicazione. Prima di adottarlo si conta quante volte negli ultimi mesi qualcuno ha aspettato un membro bloccato: se quasi mai, la modalità tradizionale basta e costa meno.

Se l'attesa è frequente, il vantaggio c'è a due condizioni: le librerie personali, senza le quali il parallelismo è solo apparente, e un controllo a occhio dei merge sui sorgenti a colonne fisse, che la guida stessa indica come il punto in cui un errore passa inosservato.