Nella prima parte di questo articolo abbiamo imparato ad usare git per tenere traccia delle modifiche effettuate ad un progetto in locale, oggi vedremo come lo si può usare per gestire in modo ordinato il lavoro di un gruppo di programmatori che lavorano sullo stesso progetto da remoto.
Come abbiamo già detto git non utilizza un server centralizzato per il controllo di versione ma utilizza invece un sistema distribuito, questo significa che non esiste un nodo “privilegiato” ma tutti i nodi sono uguali.
Vogliamo simulare un caso abbastanza semplice di condivisione: supponiamo che i due (o più) programmatori siano in una rete locale ed abbiano accesso al filesystem dove è memorizzato il repository.
Ciascun sviluppatore creerà una sua personale copia del repository con il comando
git clone REPOSITORY_PATH NUOVO_PATH
il cui output è il seguente
Cloning into learn git... done.
Cosa è avvenuto con questo comando?
- è stata creata la cartella NUOVO_PATH ed è stato inizializzato un nuovo repository all’interno di essa
- copia di tutti gli oggetti commit dal repository remoto in quello attuale
- aggiunta di un riferimeto ad un repository remoto
Così è come appare il repository appena clonato:
Va sottolineato che da questo momento tutte le modifiche fatte a tale repository avranno effetto solo su questo repository e non intaccheranno minimamente l’origine remota.
Come verificare adesso se sono state effettuate delle modifiche al repository originale?
Per fare questa verifica aggiungiamo un nuovo commit al repository originale, quindi spostiamoci nuovamente nel repository clonato ed eseguiamo:
git pull
e questo sarà il risultato:
Come fare invece ad inviare sul repository remoto le modifiche fatte al repository locale?
Il comando da usare è push; posizioniamoci quindi nel nuovo repository e digitiamo:
git push
Purtroppo notiamo subito una sfilza di errori piuttosto criptici che fanno riferimento a repository bare e roba del genere.
Gli errori non devono mai essere presi alla leggera e se per impostazione predefinita git impedisce di effettuare il push bisognerebbe chiedersi il perché.
Purtroppo una spiegazione accurata andrebbe oltre i presupposti di questo tutorial, ci basterà sapere che questa limitazione nasce per evitare che sul ramo master del repository server vengano effettuati push senza controllo.
Per inibire questo controllo bisogna modificare un’impostazione del repository originale, posizioniamoci quindi nella corretta cartella e digitiamo:
git config receive.denyCurrentBranch ignore
Fatto questo possiamo riportarci sul repository copia ed effettuare nuovamente un:
git push
In questo modo il repository originale rispecchierà tutte le modifiche fatte sulla copia, come visibile in questa immagine:
Spero che questa introduzione all’uso di Git vi sia stata utile, se vi è piaciuta potete approfondire e proseguire lo studio di questa utile risorsa cercando in internet documentazione più avanzata. Eccovi qualche link:
Esistono (e vi segnalo) inoltre alcuni tool molto comodi da usare come:
15 Responses to “Impariamo ad usare git (seconda parte)”
30 Dicembre 2011
alessandroCiao ignazio, ho avuto un’idea per un app e stavo cercando un tutorial che facesse al caso mio. Poi ho trovato un tuo tutorial (ho “scoperto” ora che sei tu l’autore) molto interessante (su come creare un app che mostra frasi random). Ho aperto un topic sul forum a tal proposito: http://forum.devapp.it/showthread.php?3603-App-iPhone-Shake-frasi-casuali&p=16610#post16610
Spero tu possa aiutarmi 🙂
4 Gennaio 2012
DomenicoCiao, molto interessante questo tutorial.
Vorrei utilizzare Git sul nostro Nas per condividere progetti.
La prima domanda riguarda l’approfondimento di cui parli nel tutorial, potresti indicarmi maggiori dettagli o un riferimento riguardo le attenzioni ad eseguire i push su un repository comune?
Se però mi dici che questa opzione è disabilitata dal 99% degli utilizzatori fa anche lo stesso.
Potrei dire delle inesattezze o delle banalità perchè alcuni aspetti mi sono oscuri avendo usato finora SVN.
Sul mio Nas QNAP dovrei installare un plugin per permettere l’utilizzo di Git.
In locale posso semplicemente usare Xcode? Mi è sembrato di vedere che gestisce il controllo del codice ma non so se usa git e se riesce a collegarsi con un archivio remoto. Oppure è necessario e conveniente usare GitHub per Mac (per non usare il terminale)?
grazie ciao
Domenico
4 Gennaio 2012
IgnaziocViene disattivato il push sul branch principale del repository remoto perché é preferibile fare il push su un branch diverso e poi fare il merge.
Io ho trovato molto interessante “comprendere git concettualmente” dagli un’occhiata.
In locale puoinusare xcode ma non permette di fare molto quindi é bene o usare il terminale oppure un tool graficoncome gitx oppure github per mac.
18 Maggio 2012
DonMizziCiao, sembra facile… e invece..
Ho clonato un repository git da un server git con gitosis.
Adesso vorrei aggiungere tutti i file di un progetto XCode e poi fare il commit e il push.
Solo che l’istruzione git add . aggiunge solo la prima cartella del progetto e non i file al suo interno e ricorsivamente le sue cartelle e file.
Cosa devo fare ora?
ricapitolando, io ho fatto:
cd repo.git
git add .
git commit -a -m “comment”
git push
e mi ha aggiunto solo la cartella myProject senza i file le sotto-cartelle al suo interno.
ho anche provato “find -iname *.* | xargs git add” senza successo
Qualcuno mi può aiutare?
grazie ciao
Don
19 Maggio 2012
IgnazioAdd è ricorsivo quindi non dovresti avere problemi.
git clone, poi copi i file , git add e git commit.
Forse hai casini se tenti di copiare una cartella che è già sotto git.
22 Maggio 2012
DonMizziEsatto, grazie per la risposta, infatti avevo compiato una cartella di un progetto Xcode che aveva già al suo interno una cartella nascosta .git.
Cancellata quella è partito tutto.
Ora provo a studiarmi con calma le guide su git che hai proposto perchè non è proprio immediato, inziamo con la differenza tra check out e clone.
Però avrei una domanda, sto usando un client grafico Gitx-L che sembra un fork ancora attivo, oggi io e il mio collega abbiamo fatto una prova aggiornando lo stesso file in due punti diversi.
Lui ha fatto il push, io ho verificato la nuova versione e, prima di fare il push (o meglio merge), avrei voluto verificare le differenze tra la mia versione locale e la versione su orgin/master.
Ma provando le varie opzioni che erano presenti non sono riuscito, potevo vedere le differenze del suo push rispetto alla versione precedente e le mie modifiche rispetto alla versione precedente. Ma non le mie modifiche rispetto alla versione attuale in remoto.
Dopo tutta questa pappardella che non so neppure se è comprensibile, volevo solo chiedere se la funzione (fondamentale) che ho chiesto è presente e non l’ho trovata oppure non è presente in GitX.
Grazie Ciao
Don
22 Maggio 2012
ignazionon conosco gitx-L, uso sempre il terminale oppure sourcetree se voglio qualcosa di grafico.
Una precisione di termini, se il tuo collega ha fatto una modifica ha fatto prima un commit e poi un push, tu se vuoi prendere la modifica devi fare un pull…ora se fai il pull il commit non è automatico quindi (non sono sicuro della soluzione) tu puoi fare un pull e verificare le differenze prima di fare un commit.
21 Novembre 2012
Diavolo_RossoCiao Ignazio,
ho seguito questa guida per tirare in piedi un mio repo git e ho seguito tutti i passaggi senza problemi. Ho dato il comando per disabilitare il blocco dei push e riesco a pushare correttamente le modifiche che faccio in locale, ma sul server non vengono caricati i file, come se il repository fosse un bare e tenesse traccia solo delle modifiche. Io invece volevo che al push dei dati venisse caricato tutto in modo da avere una copia fisica dei file anche sul server. Cosa sto sbagliando?
21 Novembre 2012
Ignaziocil mio consiglio è quello di avere un repository bare sul server. (git init –bare)
Ma questo non significa che il server conterrà soltanto le modifiche, infatti puoi benissimo fare un clone da un repository bare, semplicemente non vedrai fisicamente la struttura dei file che saranno invece tutti memorizzati all’interno dei file di git.
21 Novembre 2012
Diavolo_RossoE’ esattamente quello che non voglio. A me serviva la struttura fisica perchè trattandosi di un sito volevo che al push dei dati venisse caricato tutto e fosse già disponibile online con le modifiche apportate. Mi sembrava una buona soluzione per eliminare ogni volta l’upload via ftp
21 Novembre 2012
Ignaziocconcordo in parte sull’utilità della cosa ma non sul modo in cui la vuoi ottenere.
In certi casi può essere utile configurare il tutto in modo che ciascun commit venga automaticamente pubblicato nelle giuste cartelle (solo test, mica produzione) ma questo non significa avere un repository non bare direttamente in /var/www assolutamente no!
Il mio approccio attuale è:
– rep bare
– working copy in una cartella sul server
– script di sincronizzazione.
I commit li faccio anche più volte al giorno e certe volte renderebbero il sito non funzionate, quando finisco il lavoro e aggiorno il master vado sulla working copy, faccio un pull e lancio lo script di installazione.
L’alternativa per fare in automatico è sfruttare git hook. http://git-scm.com/book/en/Customizing-Git-Git-Hooks
21 Novembre 2012
Diavolo_RossoIl mio modo di operare è leggermente differente in quanto lavoro da solo e uso una replica del web server in locale. Quindi non avrei necessità di pushare i dati in continuazione. devo fare modifiche e commit in locale testando il sito sul mio pc e quando è tutto a posto uso il push esclusivamente come sostitutivo dell’upload.
Do comunque un occhio a git hook e vedo se ne vale la pena
21 Novembre 2012
Ignaziocscusa ma allora dove sta il problema? metti un rep bare sul server mentre in locale metti la tua wokringcopy nella cartella del webserver.
21 Novembre 2012
Diavolo_RossoMa il webserver locale per i test non è ovviamente pubblico. Se io sul server non ho la struttura fisica apache sul server cosa fa vedere?
21 Novembre 2012
Ignaziocma perché non scrivi sul forum 🙂 ??
chiaro che il webserver locale non è pubblico chi ha detto altrimenti?
facciamo così scrivi sul forum la tua configurazione (server, repository, working copy) che vediamo di trovare una soluzione.
In gni caso io ti suggerivo di avere la workingcopy nella root web, quindi avresti tutti i tuoi bei file.