La copia master #
È la copia di progetto in cui verranno consolidate tutte le modifiche, sia quelle effettuate in locale che quelle in arrivo dai fork. Solitamente la copia master è gestita dal responsabile delle release, una persona in grado di valutare la bontà del codice proprio e di quello dei collaboratori.
È certamente possibile lavorare direttamente sulla copia master, che così non deve essere una versione staccata dalle altre. Per lavorare sulla copia master è consigliabile:
- Quando si devono effettuare modifiche semplici che vengono confermate all’interno della singola giornata di lavoro, è possibile farle direttamente sul branch master.
- Se si intendono effettuare modifiche più complesse, è consigliabile usare un branch specifico. Quando la modifica è conclusa bisognerà effettuare il merge di tale branch sul master.
- Prima di effettuare qualunque operazione di commit è necessario controllare le modifiche tramite la visualizzazione delle differenze.
- Prima di effettuare qualunque operazione di merge di branch o di pull request è necessario controllare le modifiche che verranno apportate tramite il pulsante Mostra differenze (show incoming).
I fork #
Sono le copie derivate dal master da sviluppatori che collaborano al progetto insieme con il responsabile delle release. Quando si effettua un fork, verrà copiata solo la versione confermata del branch master della copia master. È quindi possibile effettuare un fork solo dopo aver eseguito almeno un commit sulla copia master.
Per lavorare sui fork è consigliabile seguire queste regole:
- Prima di iniziare una unità di lavoro, effettuare l’operazione di fetch per allinearsi al master. Siccome non esiste alcun commit nel fork che non sia stato già comunicato al master in precedenza, l’operazione di fetch non può evidenziare alcun conflitto. In caso di nascita di conflitti, vedere il paragrafo Risoluzione dei problemi.
- Eseguire il lavoro e confermare spesso. Si consiglia di non lasciare passare più di una giornata lavorativa senza effettuare un commit.
- Prima di effettuare qualunque operazione di commit è necessario controllare le modifiche tramite la visualizzazione delle differenze.
- Quando le modifiche sono terminate con successo sarà possibile inviarle al master tramite il pulsante Crea Pull Request. Il gestore del progetto master verrà avvisato automaticamente via mail.
- Prima di ripartire con una nuova unità di lavoro, effettuare nuovamente l’operazione di fetch. Occorre tenere presente che, se la pull request precedente non è ancora stata accettata, è possibile che vengano evidenziati conflitti non ancora risolti.
Conferma del lavoro #
Ogni volta che il lavoro attuale può essere confermato è consigliabile effettuare un commit, l’ideale è quello di confermare il lavoro fatto entro la giornata di lavoro.
Prima di effettuare il commit è necessario verificare le differenze per essere coscienti di quello che si sta marcando come lavoro concluso. In questa fase è consigliabile:
- Eliminare il codice commentato.
- Eliminare i console.log usati per il debug.
- Aggiungere eventuali commenti per rendere chiaro il codice agli altri sviluppatori (o a se stessi dopo qualche tempo).
- Controllare di non aver inserito metodi troppo complessi, eventualmente rendendo il codice più modulare.
- Verificare di non aver violato regole costruttive o di stile.
Esecuzione di un merge o fetch #
L’operazione di merge avviene nella copia master al momento dell’accettazione di una pull request, oppure in tutte le copie quando si tratta di unire un branch a quello master. L’operazione di fetch è simile; la sola differenza è che viene utilizzata in un fork per recuperare i nuovi commit.
L’operazione di merge deve avvenire come segue:
- Se il codice che si intende accettare è complesso o “delicato”, si consiglia di effettuare un backup della copia master prima di iniziare il merge.
- Si inizia l’operazione di merge tramite il pulsante Pull Request o Merge dalla dashboard.
- Si verificano le modifiche in entrata tramite il pulsante Mostra differenze (show incoming).
- Se le modifiche sono accettabili, si procede accettando la Pull Request, altrimenti si rifiuta la Pull Request.
- Se l’operazione di merge genera dei conflitti, si aprirà la pagina di gestione conflitti in cui dovrai decidere se mantenere le proprie modifiche, quelle della controparte oppure entrambe. Dopo aver risolto tutti i conflitti il progetto viene salvato e lo stato del branch confermato (commit).
- A questo punto è necessario controllare la correttezza del progetto effettuando almeno una operazione di compilazione al fine di controllare che:
- Il codice del progetto sia corretto
- Non siano presenti metodi duplicati
- Non siano presenti errori introdotti dall’operazione di merge.
Per quanto riguarda l’operazione di fetch, come già indicato in precedenza, si consiglia di effettuarla dopo aver inviato il proprio lavoro tramite una pull request.
Fork relativo a rilasci in produzione #
Al momento dell’installazione in produzione può essere comodo effettuare un fork del progetto in modo da avere una versione identica a quella rilasciata. In questo modo se si devono effettuare delle correzioni sulla versione rilasciata, sarà possibile farle nel fork relativo.
Se tali modifiche devono poi essere riportate nel master, basterà effettuare una pull request verso il master. È invece vietata qualsiasi operazione di fetch, che renderebbe allineato il fork al master anziché alla versione installata.
Modifiche dei file di risorse #
I file di risorse caricati nel progetto tramite upload vengono gestiti da teamworks come un blocco unico. Se essi vengono modificati contemporaneamente su più copie del progetto (master o fork), l’ultimo branch di cui si esegue il merge vince sugli altri: solo l’ultima copia di cui è stato fatto il merge entra a far parte della copia master.
Se quindi viene effettuato l’upload di un file di testo, oppure di tipo javascript client, anche se viene modificato tramite l’IDE, esso verrà sempre gestito come risorsa di tipo file e cioè come blocco unico. In questi casi è necessario organizzare le modifiche al file per essere certi che solo un programmatore alla volta le esegua, altrimenti alcune di esse potrebbero andare perse.
Risorse caricata come file