Premessa
Questo post illustra come utilizzare GIT su NetBeans in cinque passi, presupponendo:
- di aver già creato i repository di sviluppo e produzione;
- di essere in un contesto di sviluppatore singolo (quindi senza necessità di integrare nell’ambiente di produzione modifiche di altri sviluppatori).
Checklist
| Local/Remote | Azione | Istruzione git | Comando equivalente su NetBeans |
|---|---|---|---|
| Local | Creare un nuovo Branch in sviluppo | git checkout -b evo/0001-login-b = crea il branch e spostati su di esso | sulla finestra Git Repository Browser cliccare con il destro sul repository di sviluppo e poi selezionare Branch/Tag > Create Branch… (spuntare l’opzione Checkout Created Branch). |
| (Local) | Effettuare e testare le modifiche al codice | ||
| (Local) | Controllare le differenze tra index (staging area) e ultimo commit | git diff --name-only --cached | |
| Local | Portare le modifiche nella staging area (facoltativo) | git add nomefile oppuregit add . | sulla finestra Projects cliccare col destro sul file modificato e poi selezionare Git > Add. |
| (Local) | Riportare nella working directory file che sono stati aggiunti alla staging area | git restore --staged nomefile oppuregit restore --staged . | |
| Local | Confermare le modifiche (commit) | git commit -m "titolo mex" -m "corpo mex" -m "footer" | sulla finestra Git Repository Browser aprire le voci Branches > Local del repository di sviluppo e controllare di essere posizionati sul branch corretto; quindi cliccare col destro sul repository di sviluppo e poi selezionare Commit… |
| Local | Annullare una operazione di commit appena eseguita | git reset --soft HEAD~1 | cliccare con il destro sul repository di sviluppo; selezionare Revert/Recover e poi Reset; specificare HEAD^ nel campo Revision e spuntare l’opzione “Do not Modify Index or Working Tree (–soft)” (per maggiori informazioni vedere l’articolo Come annullare una Commit in Git). |
| Local | Portare le modifiche in produzione (push) | git push -u origin evo/0001-login-u = –set-upstream = collega i branch locale e remoto | sulla finestra Git Repository Browser: aprire la voce Remotes del repository di sviluppo, cliccare col destro la voce origin e selezionare push… |
| Remote | Eseguire il merge sul repository di produzione | git checkout mastergit merge evo/0001-login | sulla finestra Git Repository Browser aprire le voci Branches > Local del repository di produzione, – se il branch master non è già quello corrente, cliccare col destro sul branch master e selezionare la voce Checkout Revision… – cliccare col destro il nuovo branch (quello appena ricevuto dall’ambiente di sviluppo) e selezionare la voce Merge Revision… |
| Remote | Aggiungere un tag (facoltativo) | git tag -a v1.0.0 -m "titolo mex" | sulla finestra Git Repository Browser del repository di produzione cliccare col destro il branch master e selezionare la voce Create Tag… |
| Local | Riportare le modifiche in ambiente di sviluppo | git checkout mastergit pull origin master | sulla finestra Git Repository Browser aprire le voci Branches > Local del repository di sviluppo, cliccare son il destro sul branch master e selezionare la voce Sync with “origin/master”. |
Standard naming per i branch
Un possibile standard naming per i branch può essere il seguente: xxxx/nnnn-nome (es. evo/0015-autenticazione), dove:
- xxxx è l’abbreviazione dell’ambito della modifica da effettuare, ad esempio:
- evo per una modifica dovuta a nuovi requisiti (evolutiva funzionale);
- fix per la correzione di errori (correttiva);
- seo per una evolutiva finalizzata all’ottimizzazione SEO del sito;
- stab per una modifica di stabilizzazione del software (evolutiva tecnica).
- nnnn è un numero progressivo di modifica, riempito con zeri a sinistra;
Standard naming per i tag
Un possibile standard naming per i tag può essere il seguente: vxx.yy.zz (es: v3.1.1) dove:
- v indica proprio la lettera “v”
- xx è il numero di versione (incrementa se la commit rappresenta una significativa discontinuità con il passato);
- yy è il numero di release (incrementa ad ogni commit nell’ambito della stessa versione, escluse le fix );
- zz è il numero di change (incrementa solo per le commit di fix).
Configurare NetBeans per accedere al repository GIT sull’host di produzione
Su NetBeans è possibiloe configurare un accesso SSH al sito diproduzione per eseguire i comandi GIT. Selezionare sul menu principale le voci Team > Remote > Clone. NetBeans apre una form per l’accesso al repository di produzione. Compilare i diversi campi come indicato di seguito:
- Repository URL – inserire il valore: ssh://nomehost:porta/~/cartella
- Username – inserire il nome utente utilizzato per accedere al CPanel
- Private Key File – inserire il nome della chiave privata (non quella con suffisso .ppk) scaricata in precedenza, completo dell’intero path
- Passphrase: inserire la passphrase
- Clone into: inserire il path locale che conterrà il progetto di sviluppo (dev’essere una directory vuota)
Cliccare sul bottone “Successivo”, quindi compilare le form seguenti. Al termine, NetBeans crea una copia del repository in locale.
A questo punto è possibile utilizzare i comandi di GIT sia sul repository GIT di sviluppo (locale) che di produzione (remoto).
Risorse online
- GIT è uno strumento di controllo di versione descritto egregiamente in questa pagina e nelle seguenti: Manuale di GIT in italiano.
- NetBeans è l’ambiente di sviluppo integrato (IDE) distribuito da Oracle Corporation. NetBeans integra diversi versioning tools, compreso GIT. Per chi, come me, usa NetBeans per sviluppare applicazioni PHP, è disponibile questa guida in lingua inglese.
0 commenti