Programming Languages Hacks

Importanti regole per linguaggi di programmazione rilevanti come Java, C, C++, C#…

  • Subscribe

  • Lettori

    I miei lettori abituali

  • Twitter

Perché passare da Svn a Git

Posted by Ricibald on August 30th, 2011

Come al solito… articolo condensato per non perdere tempo…!

Perché scegliere Git rispetto agli altri controlli versione come Svn, Cvs, …? Di seguito un elenco delle cose che Git consente in più rispetto agli altri sistemi:

  1. git è distribuito: ogni client non ottiene l’ultima versione disponibile (come in Svn) ma un clone dell’intero repository con tutto lo storico. Questo abilita un uso completo offline di tutte le funzionalità (commit, diff, log, branch, merge, annotation) in modo istantaneo. Inoltre il sistema non avrà un Single Point of Failure poiché ogni client avrà il full backup del progetto. Infine si può articolare una struttura di workflow in cui si mantengono dei repository separati con diversi permessi di lettura/scrittura che vengono integrati in un workflow “gold” (si veda questo articolo) [in TFS strutturare in questo modo è possibile grazie a un uso corretto dei permessi e delle policy].
  2. branch semplici: creare un branch ed eseguire lo switch a un branch sono operazioni che impiegano qualcosa come 0.1 secondi. Tale velocità cambia l’aspetto psicologico del branch: diventa un’operazione comune per qualunque cosa su cui si lavora: ogni feature, idea, bugfix, senza essere online con la possibilità di annullare un branch e cambiare contesto quasi in modo istantaneo. Il merge inoltre è a 3 vie e riduce al minimo le probabilità di conflitti.
  3. commit organizzate per feature: a differenza di altri sistemi come Svn, in Git i file locali non vengono inviati direttamente nel repository ma passano prima per una staging area (o index) che consente di specificare nel dettaglio quali file (e quali porzioni di file) si andranno a committare, in modo da risolvere il problema della “copia di lavoro intricata” e mantenere ogni commit un evento con il preciso scopo di riportare i file modificati impattati dopo aver implementato una determinata feature. Questa separazione consente di eseguire ad esempio il merge solo di determinate feature, lasciandone indietro altre.
    Infatti Git viene definito un “change control” invece di un “version control”: invece di presentare il progetto linearmente (mentalità dell'”undo”) Git vede solo un manipolo di commit pronti per essere rimescolati o amalgamati insieme
  4. utile a te: spesso si sceglie di non usare Git poiché non si fa parte di un team numeroso. In realtà Git aiuta te, non il tuo team: il branch locale, il context switching, le commit come feature, aiutano l’individuo, non il team. Velocità e backup sono sempre una buona cosa, sia in team che non.
Ottimi articoli:

Leave a Reply

You must be logged in to post a comment.