In che modo gli sviluppatori di applicazioni professionali utilizzano i sistemi di controllo della versione, come GIT e Subversion?

Sono uno sviluppatore principiante e mi sono chiesto fin dall'inizio come utilizzare strumenti professionali come GIT e Subversion (non ho un'ottima conoscenza di questi strumenti), per soddisfare le esigenze del loro progetto. Se lo usano, come installerei qualcosa del genere?

Le mie applicazioni non sono così grandi e non sto ancora lavorando in una squadra, sarebbero di grande aiuto per me?

Ci sono domande su questo sito su come usare gli strumenti, ma ho bisogno del supporto per principianti.

Il controllo del codice sorgente è onnipresente: si potrebbe persino dire che non si può definirsi uno sviluppatore professionista se non lo si utilizza. Anche quando si sviluppa da solo, il controllo del codice sorgente offre ancora alcuni vantaggi. Alla fine fornisce sia una cronologia che un lungo percorso di annullamento. Ti consente anche di sperimentare molto di più, sicuro nella consapevolezza che se non ti piace la nuova versione, puoi sempre tornare a ciò 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 squadra a squadra. Il punto migliore da cui iniziare è probabilmente scegliere un sistema di controllo del codice sorgente e acquisire familiarità con i suoi flussi di lavoro standard (tenendo presente che dovrai cambiare i flussi di lavoro per tutta la vita professionale).

Per iniziare, consiglierei Git. Sono un fan di Git, ma la scelta più specifica di Git ti consente di iniziare a lavorare senza server e impostare un server solo quando ha senso per te. Subversion, d'altra parte, richiede un server e configurarne uno, sebbene non estremamente difficile, è scoraggiante quando non si ha familiarità con quel genere di cose.

Ecco una buona panoramica di alcune buone regole empiriche per il controllo del codice sorgente in generale: http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

Quando lavori da solo, non hai bisogno di molti flussi di lavoro. Impegnarsi presto, impegnarsi spesso. Se inizi a distribuire versioni, tagga le tue versioni. Crea rami per esperimenti o lunghi lavori divergenti (Git lo rende più economico e semplice rispetto a Subversion).

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

Non appena si lavora con altre persone in un team, i benefici 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 sezioni diverse del file) le modifiche verranno unite automaticamente. In caso di conflitti, sarai in grado di vedere le modifiche accanto ai tuoi colleghi e discutere con loro su come unire le modifiche.

Puoi anche creare istantanee del codebase (di solito chiamato tag) quando rilasci una versione del codice in modo da poter eseguire facilmente il debug dei problemi anche se la fonte principale è andata avanti 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 ottimi tutorial (video e testo) che possono aiutarti a iniziare da un livello molto semplice. Git sembra avere un ottimo approccio per introdurre l'argomento in modo delicato per i principianti che ti spiega perché prima e usa la ripetizione, la definizione e la grafica per aiutarti a ricordare i nomi e le funzioni dei comandi chiave.

SVN

SVN intendeva essere CVS fatto meglio. CVS (sistema di versione concorrente) ha lavorato su cose un file alla volta, SVN in genere ha lavorato su cose una directory o un albero di directory alla volta. SVN (e CVS o altri sistemi) possono essere importanti se lo stai usando sul lavoro, ma la mia opinione è che miglioriamo in modo significativo la nostra comprensione di ciò che serve per fare il controllo del codice sorgente ogni pochi anni, così come preferiresti un modello in ritardo computer, dovresti preferire uno strumento di controllo del codice sorgente in ritardo. È un grande investimento cambiare i sistemi e la cronologia del codice può andare persa, sebbene per molti sistemi ci siano convertitori che ti consentono di migrare il tuo codice, nonché la cronologia e altri artefatti creati dal sistema in pensione.

Il controllo del codice sorgente professionale soddisfa le esigenze professionali

La tua domanda "In che modo gli strumenti professionali utilizzano GIT e Subversion per soddisfare le esigenze del loro progetto?" si relaziona strettamente alla domanda "In che modo i team lavorano insieme senza intralciarsi l'un l'altro 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 necessitano di diversi livelli 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 modifica nel contesto con le versioni che cambiano nel tempo e spesso anche con i rami che sono copie controllate del codice che servono a isolare gruppi di modifiche da altri gruppi di modifiche.

Riunire le cose, 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é a pochi esperti. In SVN, la ramificazione potrebbe essere una questione personale, ma la fusione spesso ha avuto impatti dolorosi sulla squadra e il trasferimento del codice nella linea principale potrebbe essere doloroso dal punto di vista dell'autorizzazione, evitando rotture e il livello di sforzo necessario all'attività .

Da un repository di controllo del codice sorgente consolidato, i professionisti possono soddisfare altre esigenze come la diagnosi dei problemi alla causa principale. Se esistevano versioni del codice che funzionavano in precedenza e nuovi problemi riscontrati nella versione corrente, è possibile avanzare e retrocedere nella cronologia per individuare quando si è verificato il problema. In SVN, questa funzionalità è immatura, ma in Git la ricerca dell'ultima versione funzionante / prima non riuscita è supportata da un comando chiamato git bisect. Il problema sarà causato da una delle modifiche all'origine tra le due versioni, che è potenzialmente una diagnosi molto più semplice rispetto a una ricerca dell'intera base di codice.

Siamo spiacenti di divagare, spero che questo ti aiuti nel tuo cammino verso l'uso del controllo del codice sorgente.

Il mio team utilizza un sistema di controllo della versione del team di casa. (Purtroppo, Git non sembra funzionare ancora su file sorgente "nativi" di IBM i) Ma personalmente, una volta che ho estratto il sorgente da quel sistema, uso Git durante il mio sviluppo, fino a quando il progetto non viene completato e lo ricontrollo nel squadra VCS.

Come si dice nelle votazioni ... impegnarsi presto, impegnarsi spesso. Mentre lavoro su nuove funzionalità, mi impegno. Commetto tra le compilazioni e ad ogni tentativo di correggere gli errori del compilatore, ogni volta che apporto modifiche durante i test e il debug. Ciò consente di provare più varianti su un tema e di ripristinarlo facilmente se necessario, soprattutto quando una modifica è coordinata su più file.

Git ha migliorato il mio approccio allo sviluppo.