Originariamente inviato da Little Hawk
Giusto qualche nota aggiuntiva a quanto gia' detto da delta_machine, riguardo best practices - i.e. come utilizzare Git
nel migliore modo.
Tanto per cominciare Git e' un distributed version control system, il che vuol dire che ci possono essere N persone con diverse copie dello stesso repository, anche se con delle differenze a seconda dei 'parallel streams of development' come spesso vengono chiamati (= piu' persone lavorando su roba diversa ma sullo stesso codice).
In teoria nessuna 'copia' del repository e', diciamo, quella master/principale per via della natura distribuita di Git. Comunque, normalmente tutti i developers usano una copia del repository principale da cui fare pull come gia' detto, per scaricare aggiornamenti fatti da altri, e push per aggiornare il repository principale con i propri aggiornamenti. Quindi c'e' normalmente bisogno di un git server remoto per questo. Anche se puoi crearti un Git server da te (gitolite, gitosis, gitorious, etc...) nella maggioranza dei casi si usa un servizio di 'Git hosting', come i piu' famosi Github oppure Bitucket (c'e' anche hosted Gitorious).
Github e' il piu' popolare ma e' gratuito solo per public repositories (per es. open source) mentre Bitbucket e Gitorious sono gratuiti anche per private repositories. Personalmente uso Github per roba open source, e Bitbucket con private repositories per roba di lavoro non open source. Il repository non deve essere necessariamente remoto; per esempio ci sono molte persone che utilizzano Dropbox come repository principale.
Git funziona con branches per supportare percorsi di development paralleli da piu' persone; normalmente, ogni developer lavora su una diversa 'feature branch' se le modifiche apportate riguardano una nuova feature del prodotto, oppure su una 'hotfix' branch, se si tratta di correzioni critiche che richiedono un deployment ASAP. Una convenzione nel nominare le branches e' feature/<nome-della-feature> e hotfix/<nome-del-fix>.
Altre branches normalmente presenti sono di solito 'development', che contiene il codice in attivo development, e 'master' che normalmente dovrebbe contenere l'ultima versione del codice cosi come e' stato pubblicato/rilasciato l'ultima volta. Una volta rilasciato il contenuto di master, master dovrebbe rimanere immutabile fino al prossimo rilascio. Poi vi sono i tags: ogni volta che viene creata una release, master viene aggiornato e in più un tag viene creato di solito col numero di versione del prodotto, cosi' da poter saltare direttamente ad una specifica versione del software anche quando master e' ormai cambiato (e.g. avrai tags per v1.0.0, v1.0.1, etc per esempio).
E' importante notare che vi sono branches locali e branches remote, ovvero branches pubblicate nel repository remoto/principale, spesso chiamato 'origin'.
Funzionamento delle branches e workflow: come dicevo la branch development e' quella che contiene gli aggiornamenti fatti da tutti i developers non ancora rilasciati -e dunque non ancora presenti in master.
1) Se hai bisogno di lavorare su una nuova feature:
- Dovresti creare una nuova branch da development chiamata per convenzione feature/<nome-feature> .
- Scrivere automated tests... (spero per te che tu pratichi TDD..)
- Scrivere il codice etc..
- Fare pull della copia *remota* di origin/development (non local development, ma quella remota cosi' da includere nella propria branch aggiornamenti fatti da altri fino a quel momento)
- Verificare che tutti i tests passino / all green
- Fare checkout di development
- Fare merge o rebase della propria hot fix branch in development
- Correggere eventuali 'merge conflicts' (i.e. vi sono aggiornamenti tuoi e di altri che richiedono revisione per risolvere conflitti)
- Done! A questo punto devi semplicemente pubblicare/aggiornare development verso la sua copia remota con un push
- Cancellare feature/<nome-feature> dal momento che non serve piu'.
2) Se invece lavori su un hotfix, per definizione significa che si tratta di una correzione di un bug del prodotto cosi' come rilasciato l'ultima volta, e dunque cosi' come e' in master. Dunque:
- Dovresti create una nuova branch da master chiamata per convenzione hotfix/<nome-correzione>
- Scrivere automated tests...
- Scrivere il codice etc..
- Fare pull della copia *remota* di origin/master
- Verificare che tutti i tests passino / all green
- Fare checkout di master
- Fare merge della propria hotfix branch in master
- Done! A questo punto devi semplicemente pubblicare/aggiornare master verso la sua copia remota con un push
- Cancellare hotfix/<nome-correzione> dal momento che non serve piu'.
Quello che ho appena spiegato e' il miglior modo per usare git in un team. E' il miglior workflow tu possa trovare, ed e' il risultato di anni e anni di uso di git. Purtroppo la maggioranza delle persone utilizza git in un modo molto incasinato
Ora, detto tutto cio', la buona notizia e' che c'e' una estensione di git, chiamata
git-flow, che praticamente automatizza tutto il workflow che ho appena descritto, rendendo una best practice molto, molto semplice. Leggi un po' sul sito (e magari
http://nvie.com/posts/a-successful-git-branching-model/ se sei interessato).
Un'altra nota su best practices: e' bene dividere il lavoro in piccoli incrementi cosi' che le feature o hotfix branches siano necessarie per il piu' breve tempo possibile; in questo modo, non hai neanche bisogno di pubblicare queste branches 'temporanee' e quindi mantieni un repository remoto molto pulito, con soltanto development, master e i tags
Ovviamente puo' capitare comunque di lavorare su feature/hotfix che richiedono piu' tempo e quindi conviene pubblicarle sul repository remoto. Ma piu' lo eviti, meglio e'.
Il post e' lungo ma questa e' soltanto una introduzione...
Ma se vuoi imparare a lavorare come si deve con git, ti consiglio di utilizzare git-flow cosi' replichi facilmente il miglior workflow.
Se vuoi posso salutarti Linus Torvalds (autore ti git e linux) la prossima volta che lo vedo - la sua casa qui in Finlandia e' vicino alla mia
Rispondi quotando
