Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

--- custom:repo_git_di_commessa [2020/04/02 13:01]
mariasole.angelucci
+++ custom:repo_git_di_commessa [2021/03/04 15:01] (versione attuale)
francesco.rosati [GUIDA RAPIDA CASO BASE]
@@ Linea 14: / Linea 14: @@
 Il processo di clonazione serve a creare, nel pc dove si sta lavorando, un repository locale di Git: ogni modifica effettuata nella cartella del proprio pc non viene automaticamente salvata nel repository locale, ma deve essere esplicitamente aggiunta ad esso e, poi, deve essere riportata sul repository remoto tramite la procedura di //commit and push//.
-Per clonare il repository nel proprio pc si possono utilizzare due metodi: l'interfaccia grafica di Git per Windows, che risulta più intuitiva ma un poco più laboriosa e, in alternativa, l'interfaccia a riga di comando, che è più rapida, più versatile e più potente ma anche un po' meno intuitiva. Nei prossimi paragrafi verranno presentate entrambe le modalità. Per completezza, si riporta anche il link alla guida ufficiale di Git, in cui sono presenti le spiegazioni di tutti i comandi disponibili e delle varie opzioni per ogni comando: [[https://git-scm.com/docs]].
+Per clonare il repository nel proprio pc si possono utilizzare due metodi: l'interfaccia grafica di Git per Windows, che risulta più intuitiva ma un poco più laboriosa e, in alternativa, l'interfaccia a riga di comando, che è più rapida, più versatile e più potente ma anche un po' meno intuitiva. Nei prossimi paragrafi verranno presentate entrambe le modalità. Per completezza, si riporta anche il link alla guida ufficiale di Git, in cui si possono trovare le spiegazioni di tutti i comandi disponibili e delle varie opzioni per ogni comando: [[https://git-scm.com/docs]].
+==== Scenario Tipico ====
+=== Clonazione repository ===
+Vedi [[custom:repo_git_di_commessa#Git clone|Git clone]] sotto.
-==== Clonazione e modifica del repository tramite riga di comando ====
+=== Modifica repository tramite personalizzazione struttura ===
-In questo paragrafo saranno elencati i comandi principali di Git utilizzabili attraverso la Git bash: questo significa che tali comandi hanno valore solo se digitati all'interno dell'interfaccia a riga di comando di Git, chiamata, appunto, Git bash. Questa interfaccia può essere aperta:
+A questo punto, il responsabile di commessa deve decidere la struttura specifica da dare al progetto: si devono individuare gli ambienti necessari, che corrispondono ai diversi WAR da produrre. Bisogna quindi creare, per ognuno di essi, la relativa sotto-cartella.
+Un esempio di possibile contenuto standard di un repository di commessa è riportato in figura:
+{{ :custom:repo_di_commessa_sample.png?600 |}}
+In linea generale, quindi, la cartella di repository dovrebbe contenere:
+  * una cartella per l'ambiente interno;
+  * una cartella per ogni ambiente esterno.
+  * un'unica cartella WEB per i contenuti statici dato che, //solitamente//, sono gli stessi per tutti gli ambienti;
+Come variante di quanto sopra, le varie cartelle dei vari ambienti potrebbero ospitare **ognuna la propria cartella WEB** dei contenuti statici, oltre che eventuali cartelle //conf/// aggiuntive.
+=== Eventuale personalizzazione e produzione war ===
+Vedi la [[custom:produzione_war_da_progetto_template_custom|guida dedicata]].
+=== Salvatggio modifiche effettuate su repository git ===
+Vedi [[custom:repo_git_di_commessa#Git commit|Git commit]] e [[custom:repo_git_di_commessa#Git push|Git push]] sotto.
+==== Clonazione e gestione del repository tramite riga di comando ====
+In questo paragrafo saranno elencati i comandi principali di Git utilizzabili attraverso la Git bash: ciò significa che tali comandi hanno valore solo se digitati all'interno dell'interfaccia a riga di comando di Git, chiamata, appunto, Git bash. Questa interfaccia può essere aperta:
   * come qualsiasi programma per Windows, tramite doppio click sulla sua icona;
   * in un percorso specifico, cliccando con il tasto destro all'interno di una determinata cartella e scegliendo poi l'opzione **Git bash here**.
@@ Linea 25: / Linea 46: @@
 Dopo aver copiato il percorso di clonazione da Gitlab, andare nella cartella in cui si vuole salvare il repository e digitare il comando:
 <code>git clone percorso_copiato_da_Gitlab</code>
-Così facendo, il repository sarà clonato all'interno della cartella. Oltre ai vari file presi da remoto, nel repository locale sarà sempre presente una sotto-cartella dal nome .git che non dovrebbe mai essere eliminata o modificata. Nota: in caso vengano richieste le credenziali, vanno inserite quelle con cui ci si è registrati a Gitlab.
+Così facendo, il repository sarà clonato all'interno della cartella. Oltre ai vari file presi da remoto, nel repository locale sarà sempre presente una sotto-cartella dal nome .git che non dovrebbe mai essere eliminata o modificata. Si noti che, in caso vengano richieste le credenziali, vanno inserite quelle con cui ci si è registrati a Gitlab.
 === Git status ===
@@ Linea 34: / Linea 55: @@
 === Git add ===
-Per eseguire l'operazione di //commit//, quindi per salvare le modifiche locali anche sul repository remoto, bisogna inizialmente aggiungere i file che si vogliono salvare nell'elenco degli //staged files// tramite il comando "add"; in particolare, per salvare tutti i file bisogna utilizzare il comando
+Per eseguire l'operazione di //commit and push//, quindi per riportare le modifiche locali anche sul repository remoto, bisogna inizialmente aggiungere i file che si vogliono salvare nell'elenco degli //staged files// tramite il comando "add"; in particolare, per salvare tutti i file bisogna utilizzare il comando
 <code>git add all</code>
-Oppure si possono scegliere i singoli file da aggiungere scrivendo
+S possono anche scegliere i singoli file da aggiungere scrivendo
 <code>git add nome_del_file</code>
-Con questo comando è possibile formare anche delle espressioni, in modo da raggruppare una certa tipologia di file ed aggiungere più elementi tutti insieme, ad esempio:
+Con questo comando, inoltre, è possibile utilizzare anche delle espressioni, in modo da raggruppare una certa tipologia di file ed aggiungere più elementi nello stesso momento. Ad esempio, per aggiungere alla lista degli //staged files// tutti quelli che hanno l'estensione TXT, basta scrivere:
 <code>git add *.txt</code>
-per aggiungere alla lista degli //staged files// tutti i file con estensione TXT.
 Per ulteriori opzioni e utilizzi del comando "git add", si rimanda alla sezione specifica nella guida ufficiale di Git: [[https://git-scm.com/docs/git-add]].
 === Git commit ===
-Il passo successivo è eseguire il //commit// vero e proprio dei files, utilizzando, appunto, il comando "commit". Inoltre, è necessario, anche in questo caso, aggiungere un breve commento come descrizione delle modifiche effettuate; il commento va aggiunto dopo l'opzione "-m", come riportato qui di seguito:
+Il passo successivo è l'esecuzione del //commit// vero e proprio dei file, utilizzando, appunto, il comando "git commit". Per questa operazione, è sempre necessario aggiungere un breve commento così da descrivere le modifiche effettuate; il commento va aggiunto dopo l'opzione "-m", come riportato qui di seguito:
 <code>git commit -m "This is a simple comment for a commit"</code>
 Per conoscere tutte le numerose opzioni del comando "git commit", è possibile consultare la sezione apposita nella guida ufficiale: [[https://git-scm.com/docs/git-commit]].
@@ Linea 57: / Linea 77: @@
 === Git pull ===
-Se si vuole aggiornare il proprio repository locale alle modifiche più recenti avvenute in remoto, si deve utilizzare (all'interno della cartella in cui si trova il repository locale) il comando
+Se si vuole aggiornare il proprio repository locale con le modifiche più recenti presenti in remoto, si deve utilizzare (all'interno della cartella in cui si trova il repository locale) il comando
 <code>git pull</code>
 Questo comando permette di recuperare e incorporare ai file già presenti nella propria cartella, tutte le modifiche fatte sul server remoto. Si noti, comunque, che questo implica che le modifiche avvenute in remoto andranno a sovrascrivere quelle nella cartella di lavoro, allineando perfettamente il repository locale con quello remoto: tutti i file aggiunti o modificati in locale saranno scartati se non presenti o non modificati in remoto.
-Altre indicazioni sull'uso di "git pull" possono essere recuperate nella guida ufficiale seguendo il link [[https://git-scm.com/docs/git-pull]]
+Altre indicazioni sull'uso di "git pull" possono essere trovate nella guida ufficiale seguendo il link [[https://git-scm.com/docs/git-pull]].
 === Git merge ===
@@ Linea 71: / Linea 91: @@
 Prima di eseguire questa operazione, però, è necessario che i //branch// che si vogliono unificare siano stati correttamente salvati, cioè che le modifiche locali siano allineate con quelle remote (si può verificare la condizione con il comando "git status"). Git, infatti, opera considerando che le versioni valide di ogni //branch// siano sempre e solo quelle salvate nei corrispettivi repository remoti: tutte le modifiche non salvate in remoto verranno perse.
-Chiaramente, per l'operazione di //merge// si deve partire da un //branch//: assicurarsi che si faccia riferimento al //branch// giusto con il comando
+Chiaramente, per l'operazione di //merge// si deve partire da un primo //branch// e ci si può assicurare di fare riferimento al //branch// giusto con il comando:
 <code>git checkout nome_del_branch_di_partenza</code>
-A questo punto, basta utilizzare il comando
+A questo punto, per unire il primo ramo al secondo, basta utilizzare il comando:
 <code>git merge nome_del_branch_da_unire</code>
-Se i due rami non hanno modificato gli stessi file, l'operazione termina così. In caso contrario, invece, Git riporterà un conflitto fra i //branch//, indicando quali file e quali parti di essi sono in contraddizione, e l'operazione di unione non verrà effettuata. Per completare il //merge// si dovrà andare a modificare i file che creano conflitto in modo da renderli uguali.
+Se i due rami non hanno modificato gli stessi file, l'operazione terminerà così. In caso contrario, invece, Git riporterà un conflitto fra i //branch//, indicando quali file e quali parti di essi sono in contraddizione, e l'operazione di unione non verrà effettuata. Per completare il //merge// si dovrà andare a modificare i file che creano conflitto in modo da renderli uguali.
 L'operazione di //merge// è un'operazione centrale di Git, e, per questo, esistono molteplici opzioni e utilizzi del comando "git merge". Per approfondire è possibile consultare la guida ufficiale al seguente link: [[https://git-scm.com/docs/git-merge]].
@@ Linea 81: / Linea 101: @@
 ==== Clonazione e modifica del repository tramite interfaccia grafica ====
 Aprire nel proprio pc il percorso su cui si vuole salvare il progetto, cliccare all'interno della cartella con il tasto destro e selezionare l'opzione **Git GUI here**. Nella finestra che viene aperta, scegliere **Clone existing repository** (come mostrato in figura) e, a questo punto, incollare nel form **Source location** il path precedentemente copiato dal progetto Gitlab; nel form **Target directory**, invece, va inserito il percorso, all'interno del proprio pc, all'interno del quale si vuole salvare il progetto.
-Procedere cliccando sul pulsante **Quit** e, dopo qualche istante, la clonazione del repository di Git sarà completata: il progetto e tutti gli eventuali file contenuti al suo interno saranno ora presenti anche nel proprio pc. Anche in questo caso, oltre ai vari file, sarà presente nel repository locale una sotto-cartella chiamata .git che contiene varie opzioni di configurazione e che non dovrebbe essere modificata o eliminata.
+Procedere cliccando sul pulsante **Quit** e, dopo qualche istante, la clonazione del repository di Git sarà completata: il progetto e tutti gli eventuali file contenuti al suo interno saranno ora presenti anche nel proprio pc. Anche in questo caso, oltre ai vari file, sarà presente nel repository locale una sotto-cartella chiamata .git che contiene varie opzioni di configurazione e che non dovrebbe essere modificata o eliminata. Come nel caso precedente, in caso di richiesta, inserire le proprie credenziali di Gitlab.
- Nota: come nel caso precedente, in caso di richiesta, inserire le proprie credenziali di Gitlab.
 {{ :custom:gitgui_cloneproject.png?600 |}}
@@ Linea 106: / Linea 124: @@
 ==== Casi tipici di utilizzo ====
 Nonostante l'estrema versatilità di uno strumento come Git, è possibile che alcune procedure o alcuni comandi descritti nei paragrafi precedenti siano, in qualche caso, ridondanti o non utili. Per semplificare le operazioni, quindi, qui di seguito sono elencati alcuni casi standard in cui si deve utilizzare Git e i quali necessitano solo di alcuni comandi.
-  * Il repository di commessa __non è condiviso__: questo significa che si è i soli a lavorare con esso e, perciò, non è necessario creare ramificazioni complesse. Dopo aver clonato una sola volta il repository nella propria macchina, basterà riportare in remoto, di volta in volta, le modifiche effettuate. Questo significa che le uniche operazioni che devono essere eseguite tramite Git sono quelle di //commit// e //push//; di conseguenza, gli unici comandi che devono essere usati sono "git add", "git commit" e "git push".
+  * Il repository di commessa __non è condiviso__: questo significa che si è i soli a lavorare con esso e, perciò, non è necessario creare ramificazioni complesse. Dopo aver clonato una sola volta il repository nella propria macchina, basterà riportare in remoto, di volta in volta, le modifiche effettuate. Ciò vuol dire che le uniche operazioni che devono essere eseguite tramite Git sono quelle di //commit// e //push//; di conseguenza, gli unici comandi che devono essere usati sono: <code>git add all</code><code>git commit -m "Inserire il messaggio di descrizione della modifica"</code> <code>git push</code>
-  * Il repository di commessa __è condiviso__: più persone devono lavorare allo stesso repository, anche tramite macchine diverse. In questo caso è bene mantenere sempre sia il repository remoto sia tutti i repository locali allineati alle varie modifiche per evitare errori e conflitti. Questo significa che, prima di apportare cambiamenti, si deve controllare che il proprio repository sia aggiornato con quello remoto tramite il comando "git pull" e, eventualmente, "git merge". Solo dopo essersi assicurati che tutto sia correttamente allineato, è possibile apportare le proprie modifiche e poi eseguire l'operazione di //commit// e //push//.
+  * Il repository di commessa __è condiviso__: più persone devono lavorare allo stesso repository, anche tramite macchine diverse. In questo caso è bene mantenere sempre sia il repository remoto sia tutti i repository locali allineati alle varie modifiche per evitare errori e conflitti. Questo significa che, prima di apportare cambiamenti, si deve controllare che il proprio repository sia aggiornato con quello remoto usando il comando "git pull" (ed eventualmente "git merge"). Solo dopo essersi assicurati che tutto sia correttamente allineato, è possibile apportare le proprie modifiche e poi eseguire l'operazione di //commit// e //push//. Quindi, in questo caso, il comando da utilizzare prima della modifica è: <code>git pull</code> Mentre dopo la modifica: <code>git add all</code><code>git commit -m "Inserire il messaggio di descrizione della modifica"</code> <code>git push</code>