Git Mode di Project4i: che cosa cambia per i sorgenti

Project4i ha documentato Git Mode, la modalità che porta Git dentro i progetti IBM i gestiti dall'estensione. La funzione non è ancora attiva: la guida utente del 23 settembre 2026, intestata alla versione 0.4.0, la dichiara in fase di finalizzazione, e l'ultima versione pubblicata sul Marketplace è la 0.3.9.

Il progetto nel suo insieme è descritto in Project4i: e se i sorgenti avessero un progetto?. Qui si parla solo di quello che cambia con Git.

Il principio

Nella formulazione della documentazione, Git diventa il modo in cui il sorgente viene versionato e condiviso, mentre Project4i resta il modo in cui il software arriva in produzione.

Il repository è ospitato sull'IFS del proprio IBM i. L'oggetto che raggiunge ciascun ambiente viene costruito a partire da un commit, dal motore di promozione che Project4i usa già oggi.

La scelta per progetto

La modalità si sceglie quando si crea il progetto. Un progetto senza modalità esplicita è tradizionale, e i progetti esistenti restano tradizionali: non sono previste né migrazione né conversione dei dati. Chi usa già Project4i non vede cambiare niente finché non crea un progetto Git.

Un merge non scrive in produzione

È la scelta più rilevante. Un merge avvia al massimo un deploy verso DEV; da lì lavora il motore esistente, con backup prima della promozione, criteri di autorizzazione, controllo sui file dati, registro dei deploy e rollback. La documentazione ne dà due motivi:

• Separazione dei compiti. Se il merge scrivesse in produzione, chiunque abbia il diritto di fare merge potrebbe scrivere 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, senza che nulla lo segnali.

I sorgenti a formato fisso

• Una cartella per file sorgente, come src/QRPGLESRC/PGM1.RPGLE: un PGM1 in QRPGLESRC e uno in QCLLESRC restano due file distinti invece di sovrascriversi.
• Il blocco del membro diventa un avviso, e di proposito non esiste un livello bloccante. L'avviso resta perché, secondo la documentazione, su RPG III, RPG IV e DDS un merge automatico può produrre righe sintatticamente valide con i campi nelle colonne sbagliate.
• La lunghezza delle righe si controlla prima del commit. Una riga più lunga di quanto il membro può contenere viene rifiutata con il numero di riga, perché IBM i la troncherebbe senza far fallire il comando.

Le librerie di sviluppo personali

Due sviluppatori su due branch che compilano nella stessa libreria si sovrascrivono a vicenda credendo di essere isolati. Per questo la libreria di sviluppo può essere una per progetto, come avviene di serie, oppure una per sviluppatore. Un nome oltre i dieci caratteri ammessi da IBM i viene rifiutato e mai accorciato: accorciandolo, due sviluppatori con nomi simili finirebbero sulla stessa libreria.

Esempio: due sviluppatori sullo stesso programma

Anna e Luca devono modificare lo stesso programma, PGM1 in QRPGLESRC.

In un progetto tradizionale Anna blocca il membro. Luca vede il lucchetto con il nome di chi lo tiene e aspetta che venga rilasciato.

In un progetto Git con librerie personali:

1. Ciascuno lavora sul proprio branch, sul file locale src/QRPGLESRC/PGM1.RPGLE.
2. Ciascuno compila nella propria libreria di sviluppo, senza toccare quella dell'altro.
3. Luca riceve l'avviso che Anna sta lavorando sullo stesso membro. Non lo ferma, ma gli dice che al merge le colonne vanno ricontrollate.
4. Al commit, una riga troppo lunga viene rifiutata con il suo numero.
5. Il merge avvia al massimo un deploy in DEV. Da DEV in avanti la pipeline è quella di oggi, con backup e approvazioni.

Che cosa serve sul sistema

Git Mode richiede git sull'IBM i e un client SSH, e tratta la chiave SSH come requisito. La documentazione descrive un Setup Health Check che segnala git mancante, una versione troppo vecchia o il client SSH mancante, con una gravità che dipende dall'uso effettivo di Git Mode. La versione minima di git non è indicata.

La guida elenca quattro problemi, dichiarati osservati su un IBM i reale e gestiti dall'estensione:

Il secondo vale anche per le verifiche fatte a mano: un «not found» ottenuto su una connessione SSH non interattiva non prova che git manchi.

Stato del rilascio

Quando conviene

Git Mode risolve il lavoro in parallelo sulla stessa applicazione. Prima di adottarlo, la domanda da farsi è quante volte negli ultimi mesi qualcuno ha dovuto aspettare un membro bloccato: se la risposta è quasi mai, la modalità tradizionale basta e costa meno.

Se invece l'attesa è frequente, il vantaggio c'è a due condizioni. La prima sono le librerie personali, senza le quali il parallelismo è solo apparente. La seconda è un controllo a occhio dei merge sui sorgenti a colonne fisse, che la documentazione stessa segnala come il punto in cui un errore passa inosservato.