In che modo gli sviluppatori di applicazioni professionali usano sistemi di controllo delle versioni, come GIT e Subversion?

Il controllo del codice sorgente è onnipresente - si potrebbe anche dire che non puoi definirti uno sviluppatore professionista se non lo stai utilizzando. Anche quando si sviluppa da solo, il controllo del codice sorgente offre ancora alcuni vantaggi. Alla fine fornisce sia una cronologia che un percorso di annullamento esteso. Ti libera anche di sperimentare molto di più, sicuro che se non ti piace la nuova versione, puoi sempre tornare a quello che avevi prima.

Detto questo, i flussi di lavoro, anche all'interno di un sistema di controllo del codice sorgente come Subversion o Git, variano immensamente da un team all'altro. Il miglior punto di partenza è probabilmente quello di scegliere un sistema di controllo del codice sorgente e familiarizzare con i flussi di lavoro standard (tenendo a mente che dovrai cambiare i flussi di lavoro per tutta la tua vita professionale).

Per iniziare, consiglierei Git. Sono un fan di Git, ma nello specifico scegliendo Git gets è possibile iniziare a lavorare senza server e configurare un server solo quando ha senso per te. Subversion, d'altra parte, richiede un server e impostarne uno, anche se non estremamente difficile, è scoraggiante quando non si ha familiarità con questo genere di cose.

Ecco una buona panoramica di alcune buone regole pratiche per il controllo del codice sorgente in generale: link

Quando lavori da solo, non hai bisogno di una buona dose di flusso di lavoro. Impegnati presto, commetti spesso. Se inizi a distribuire versioni, tagga le tue versioni. Crea filiali per esperimenti o lavori lunghi e divergenti (Git rende questo più economico e semplice rispetto a Subversion).

I sistemi di controllo del codice sorgente (SVN, Git ecc.) ad un livello molto semplicistico ti consentono di mantenere la cronologia delle modifiche dei file. Ciò ti consente di vedere come il tuo codice è cambiato nel tempo e di eseguire il rollback delle modifiche che potresti non volere (ad esempio, se la modifica non funziona come previsto, puoi ripristinare il codice in uno stato precedentemente noto). Questo è qualcosa che anche sviluppando da solo diventerà prezioso per te una volta che inizi a usarlo.

Non appena lavori con altre persone in una squadra, i vantaggi aumentano ancora di più in quanto più persone possono cambiare lo stesso file e se le modifiche non sono in conflitto (ad esempio 2 persone cambiano diverse sezioni del file) le modifiche sarà unito automaticamente. Se ci sono conflitti, sarai in grado di vedere le tue modifiche accanto ai tuoi colleghi e discutere con loro come unire le modifiche.

Puoi anche creare istantanee della base di codice (solitamente chiamata tag) quando rilasci una versione del codice in modo da poter facilmente eseguire il debug dei problemi anche se la sorgente principale è stata spostata con nuove funzionalità che potrebbero non essere ancora state rilasciate.

Ecco alcune risorse utili:

Avvio e esecuzione di Subversion e Tortoise SVN con Visual Studio e .NET

Controllo versione con Subversion

Tutorial per principianti

Esistono tutorial fantastici (video e testo) che possono aiutarti a iniziare da un livello molto semplice. Git sembra avere un ottimo approccio a introdurre l'argomento in modo gentile per i principianti che ti spiegano il perché e utilizza la ripetizione, la definizione e grafica per aiutarti a ricordare i nomi e le funzioni dei comandi principali.

SVN

SVN intendeva essere fatto meglio con il CVS. CVS (concurrent Version System) lavorava su cose un file alla volta, SVN di solito lavorava su cose una directory o un albero di directory alla volta. SVN (e CVS o altri sistemi) possono essere importanti se lo si utilizza al lavoro, ma la mia opinione è che miglioriamo significativamente la nostra comprensione di ciò che serve per fare il controllo del codice sorgente ogni pochi anni, così come si preferirebbe un modello in ritardo computer, si dovrebbe preferire uno strumento di controllo del codice sorgente avanzato. È un enorme investimento per cambiare i sistemi e la cronologia del codice può essere persa, sebbene per molti sistemi ci siano convertitori che consentono di migrare il codice oltre alla cronologia e ad altri artefatti creati dal sistema che si sta ritirando.

Il controllo sorgente professionale soddisfa le esigenze professionali

La tua domanda "In che modo gli strumenti di utilizzo professionale come GIT e Subversion soddisfano le esigenze dei loro progetti?" si collega strettamente alla domanda "In che modo le squadre lavorano insieme senza entrare negli altri mentre continuano a lavorare il più rapidamente possibile?"

Il codice sta cambiando frequentemente con alcuni sviluppatori che creano codice che altri sviluppatori useranno e con una varietà di parti interessate che hanno bisogno di livelli diversi di stabilità rispetto all'innovazione. I sistemi di controllo del codice sorgente aiutano a memorizzare il codice per l'uso da parte del team, mantenendo ogni cambiamento nel contesto con versioni che cambiano nel tempo e spesso anche con rami che sono copie controllate del codice che servono a isolare i gruppi di modifiche da altri gruppi di modifiche.

Riportare le cose insieme, unire il lavoro di molti membri del team è un compito che in SVN e nei sistemi precedenti era centralizzato e difficile. Per i team che utilizzano Git, la fusione diventa più semplice e accessibile all'influenza dell'intero team anziché di alcuni esperti. In SVN, la ramificazione potrebbe essere una questione personale, ma la fusione spesso ha avuto effetti dolorosi sulla squadra e il movimento del codice nella linea principale potrebbe essere doloroso dal punto di vista dell'autorizzazione, evitando la rottura e il livello di sforzo necessario per il compito .

Da un repository di controllo del codice sorgente stabilito, i professionisti possono soddisfare altre esigenze come la diagnosi dei problemi per la loro causa principale. Se esistevano versioni del codice che funzionavano e problemi rilevati di recente nella versione corrente, è possibile avanzare e retrocedere nella cronologia per individuare il punto in cui si è verificato il problema. In SVN questa capacità è immatura, ma in Git la ricerca dell'ultima versione funzionante / prima fallita è supportata da un comando chiamato git bisect. Il problema sarà causato da una delle modifiche di origine tra le due versioni che è potenzialmente una diagnosi molto più semplice di una ricerca dell'intero codebase.

Spiacente di divagare, spero che questo ti aiuti a utilizzare il controllo del codice sorgente.

Il mio team utilizza un sistema di controllo della versione del team cresciuto in casa. (Purtroppo, Git non sembra funzionare ancora sui file di origine "nativi" di IBM i) Ma personalmente, una volta estratta la fonte da quel sistema, utilizzo Git durante il mio sviluppo, fino a quando il progetto è terminato e lo ricontrollo nel squadra VCS.

Come si suol dire nel votare ... impegnarsi presto, impegnarsi spesso. Mentre lavoro su nuove funzionalità, commetto. Mi impegno tra le compilazioni e ad ogni tentativo di correggere gli errori del compilatore, ogni volta che apporto delle modifiche durante il test e il debug. Ciò consente di semplificare la prova di diverse varianti su un tema e di ritirarlo facilmente, se necessario, specialmente quando un cambiamento è coordinato su più file.

Git ha migliorato il mio approccio allo sviluppo.