custom:repo_git_di_commessa

Differenze

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

Link a questa pagina di confronto

Entrambe le parti precedenti la revisione Revisione precedente
Prossima revisione
Revisione precedente
custom:repo_git_di_commessa [2020/04/02 17:54]
mariasole.angelucci [Clonazione e modifica del repository tramite riga di comando]
custom:repo_git_di_commessa [2021/03/04 15:01] (versione attuale)
francesco.rosati [GUIDA RAPIDA CASO BASE]
Linea 16: Linea 16:
 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]]. 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 === 
 +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: 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; ​   * come qualsiasi programma per Windows, tramite doppio click sulla sua icona; ​
Linea 103: Linea 124:
 ==== Casi tipici di utilizzo ==== ==== 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. 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>​ 
 + 
 + 
  • custom/repo_git_di_commessa.1585842882.txt.gz
  • Ultima modifica: 2020/04/02 17:54
  • da mariasole.angelucci