Working copy #
È la copia del progetto su cui si sta lavorando. Può essere la copia master se è quella utilizzata come base da cui effettuare i fork, oppure una copia derivata se, appunto, è stata ottenuta come fork da una versione master.
Commit #
Una unità di lavoro confermata, espressa come l’insieme minimo di modifiche necessarie per passare dalla versione confermata attuale alla versione confermata precedente.
Fork #
Creazione di una copia di un progetto, solitamente nell’account di un altro programmatore. La versione copiata mantiene il legame con la versione master, potendo inviare i propri commit o ricevere le modifiche presenti nella versione master. Il fork contiene solo il branch master confermato, non contiene quindi la parte di lavoro non ancora confermata della copia master.
Branch #
Una versione alternativa sempre contenuta all’interno della propria working copy. Per ogni working copy esiste sempre almeno un branch (quello master). È possibile creare nuovi branch, utili quando si desidera implementare parti complesse che non possono essere confermate fino al termine del lavoro e, al contempo, potrebbe essere necessario proseguire il lavoro anche nella versione che non contiene tali modifiche.
A differenza di GitHub, con Team Works non è necessario sempre creare nuovi branch all’inizio di una unità di lavoro, lo si fa solo in casi specifici, come nell’esempio precedente.
Merge #
L’operazione di unione dei commit effettuati su un determinato branch o fork all’interno di un altro branch, solitamente quello master. Se, ad esempio, si è concluso con successo il lavoro effettuato su uno specifico branch è opportuno renderlo disponibile a tutti effettuando il merge del branch all’interno di quello master e poi cancellando il branch specifico dopo il controllo del risultato del merge.
Pull request #
L’operazione di invio dei commit effettuati in un fork verso la versione master. Tali commit verranno poi uniti all’intero della versione master con una operazione di merge.
Fetch #
L’operazione di recupero di nuovi commit presenti nella versione master a partire da un fork. In questo modo il fork si allinea alla versione master ed è possibile proseguire con una nuova unità di lavoro.
L’operazione di fetch esegue una rebase del fork su cui viene eseguita. Cioè, se il fork su cui viene eseguita la fetch non è allineato al master, per prima cose vengono annullate le modifiche presenti nel fork, poi vengono acquisite le modifiche arrivate dal master ed infine vengono nuovamente eseguite le modifiche annullate in precedenza. Se tali modifiche non possono essere eseguite a causa delle variazioni ottenute dal master, si possono ottenere dei conflitti al termine della fase di fetch. Per evitare questa situazione, prima di eseguire una fetch si consiglia di inviare al master le modifiche presenti nel fork tramite una pull-request, accettare la pull-request ed infine allinearsi al master.
Reset #
L’operazione di annullamento di tutte le modifiche non confermate nel branch in fase di modifica. In pratica si ritorna all’ultima versione confermata senza poter più recuperare le modifiche annullate, a meno di non ripristinare un backup dell’intero progetto.
Revert #
L’operazione di annullamento delle modifiche apportate ad un progetto da parte di un determinato commit. Essa avviene creando un nuovo commit che contiene una versione invertita del commit precedente. Al posto della revert è possibile ripristinare un backup del progetto prima del merge che ha causato problemi.
Conflitto #
Durante le operazioni di merge e di fetch possono avvenire conflitti se uno stesso oggetto è stato modificato da entrambi i lati, cioè all’interno dei commit in fase di merge e anche nella versione in cui si sta facendo il merge.
Durante l’operazione sarà necessario risolvere il conflitto, cioè scegliere quale versione mantenere: quella attuale, quella che proviene dai commit in fase di merge, o anche entrambe in alcune occasioni. Dopo aver risolto tutti i conflitti sarà inoltre necessario verificare se occorre correggere manualmente il progetto per completare l’integrazione dei nuovi commit con lo stato precedente. È quindi molto importante lavorare in modo da evitare il più possibile i conflitti, modificando le stesse parti di progetto.
Visualizzazione differenze #
Prima di effettuare le operazioni di gestione del progetto (commit, merge, fetch) è necessario valutare l’impatto delle stesse tramite le funzioni di visualizzazione differenze che Team Works include. Solo dopo aver osservato e valutato la bontà del codice che si sta confermando o unendo alla versione attuale sarà opportuno continuare con l’operazione vera e propria.