Lavoro in un dipartimento in cui nessuno ha mai usato il controllo del codice sorgente, incluso me stesso.

Sto cercando di spingere il concetto. Ho trascorso un po 'di tempo alla ricerca di SVN. Ho imparato alcune nozioni di base. Posso creare / aggiornare / fare il checkout / commit con riga di comando e da Tortoise. Sto iniziando a imparare come taggare e ramificare ma ancora confuso molto sui conflitti tra rami e tronco ecc. Sto ancora imparando, ma non ho una persona fisica che possa mostrarmi qualsiasi cosa. È tutto da libri / tutorial e prove ed errori.

Da quello che ho letto online sembra che gitsia la cosa migliore da sapere, ma è anche più complicato. Non voglio sopraffare me stesso. Dovrei continuare a padroneggiare svn prima di passare a git o sarei più saggio saltare semplicemente a git ora?

Ci sono pro e contro di entrambi gli approcci?

No

Git è così radicalmente diverso da SVN che non ti aiuterà. Semmai cercherai i comandi "aggiorna" e "commetti" e ti chiedi perché tutto è diverso.

Inizia con Git dal basso verso l'alto e vai da lì.

Contrastare un sistema centralizzato standard di aggiornamento / commit del versioning del modello con Git è come confrontare un bus con il trasporto di massa. Un autobus ti porterà (e tutti gli altri) dal punto A al punto B usando esattamente lo stesso percorso. Il trasporto di massa ti porterà dal punto A al punto B usando qualsiasi percorso ti piaccia.

La distribuzione stessa presenta degli svantaggi di cui dovresti essere consapevole. Ci vuole più lavoro per mantenere tutti sulla stessa pagina. Offre tuttavia un enorme aumento della flessibilità.

Hash di revisione vs. numeri

Qualcuno ha menzionato Git usando gli hash SHA1 mentre Hg usa i numeri.

Per prima cosa raramente (se mai) hai bisogno di gestire direttamente gli hash negli commit / pull giornalieri. Devi estrarre il registro e estrarre gli hash se stai facendo diff o alcuni degli elementi di rebasing più difficili.

Con Git, tutti hanno gli stessi hash. Repository diversi non hanno numeri di commit diversi e tutti si trovano sulla stessa pagina. Con Hg questo è meno. In pratica, se devi recuperare gli hash di commit e lavorare con loro (sia per confrontare o attraversare la sequenza temporale del codice), è più facile sincronizzare con altre persone quando hai hash anziché numeri.

No, per favore, non preoccuparti nemmeno.

Seriamente, inizia da un DVCS. Il fatto che SVN sia popolare non lo rende lo standard. Linus Torvalds ti direbbe che potrebbe marcire il tuo cervello .

Leggi questo fantastico articolo / introduzione di Joel Spolsky intitolato Subversion Re-education .

Potresti anche essere interessato a leggere quest'altra domanda: sono un fanatico di Subversion, perché dovrei considerare o non considerare Mercurial o Git o qualsiasi altro DVCS?

Scelta tra DVCS

Personalmente, uso sia mercurial che git, e penso che sia importante conoscerli entrambi. Una lettura consigliata a riguardo è Git vs. Mercurial: Please Relax (vedi l'esempio git-addremove). Due citazioni da quell'articolo che penso riassumano.

Per quanto riguarda git:

La filosofia di progettazione di Git è inconfondibilmente quella di Unix: a differenza di Subversion, CVS o Mercurial, git non è un binario monolitico ma una moltitudine di singoli strumenti, che vanno dai comandi di "porcellana" di alto livello come git-pull, git-merge e git-checkout per comandi "idraulici" di basso livello come git-apply, git-hash-object e git-merge-file. Quindi, come MacGyver, puoi fare praticamente tutto ciò di cui hai bisogno con Git - questo include motori Wiki assolutamente fantastici, tracker di problemi, filesystem, strumenti di sysadmin - tutto a parte la riparazione dei fusibili.

Per quanto riguarda mercurial:

Gli sviluppatori a cui piace mantenere pulito il proprio sistema apprezzeranno probabilmente il fatto che hg installa un binario in contrasto con il 144 che costituisce git, e gli sviluppatori che pensano che la capacità di git di modificare i tuoi precedenti commit sia idiota, non necessaria e pericolosa apprezzerà il semplicità che hg offre omettendo quella particolare caratteristica.

Molti progetti possono essere trovati su github e git è più potente, ma può anche essere un po 'intimidatorio per i nuovi arrivati, specialmente per gli utenti di Windows. C'è anche bitbucket (l'equivalente di github per mercurial).

Il mio consiglio: inizia con mercurial e non appena ti senti a tuo agio, prendi git; non riguarda gli strumenti, riguarda le persone con cui lavori .

Quello che considero l'uso reale e pratico di Subversion è, non per lavorare con altre persone, ma forse per implementare un programma di aggiornamento per le tue applicazioni di produzione, ecco perché:

• Attualmente, svn è quasi installato nella maggior parte dei provider di hosting
• Ha un buon supporto per i sottoprogetti (risolvibile ora in git e hg). svn upe il tuo progetto e le sue dipendenze vengono aggiornati.

Citando Thorbjørn su quest'altra discussione :

I DVCS sono Subversion, ciò che Bittorrent è ftp

Modifica : se c'è un VCS che dovresti conoscere prima di Git, potrebbe essere Mercurial (un'interfaccia CLI molto più intuitiva e buona per essere introdotta ai concetti distribuiti). Questo consiglio si applica specialmente a coloro che provengono da Subversion poiché la CLI è anche simile in una certa misura. Il Controllo versione distribuito può essere più facile da imparare rispetto al Controllo versione centralizzato, poiché ti preoccupi solo dell'istanza del repository e non delle parti client e server in modo separato .

Dovresti imparare cosa intendi usare. Git è popolare, così come anche Mercurial ha goduto di popolarità. Git / Mercurial sono entrambi sistemi di controllo del codice sorgente distribuiti.

La cosa più importante quando si introduce un nuovo concetto in un team (ed è un peccato che il controllo di versione sia considerato un nuovo argomento per troppi team), aiuta a delineare i propri obiettivi e criteri di valutazione. Non devi essere super-formale a riguardo, ma poniti le seguenti domande:

• Qual è lo scopo del controllo della versione nel nostro team. Sì, tutti i sistemi di controllo della versione che valgono qualcosa ti permetteranno di tornare indietro nella storia e vedere cosa è cambiato in ogni dato file. Tuttavia, lo userai per basare le nuove versioni? (annuisci con la testa, vuoi questo). Questa è la dichiarazione di visione a 2-3 righe per ciò che vuoi realizzare.
• Il tuo team è abituato ad avere il proprio ambiente di lavoro locale solo per unire attentamente le cose in seguito? In tal caso, il percorso DVCS potrebbe avere più senso.
• Al contrario, il tuo team è abituato a lavorare da un'unità condivisa e tutto è in costante integrazione? In tal caso, il VCS più tradizionale potrebbe avere più senso.

Nel valutare le tue alternative, devi considerare le cose importanti che tutte le VCS devono fare:

• Codice di base (rami con tag, etichette, ecc.). Fondamentalmente, come si ottiene il codice sorgente esatto utilizzato in una versione del progetto.
• Ricevi le modifiche locali al server centrale. È necessario disporre di una copia autorevole del codice, sia che si utilizzi DVCS o VCS standard. Ogni strumento tratta questo processo in modo diverso.
• Ricevi le modifiche nel server centrale nella tua copia locale.
• Come affrontare i cambiamenti sperimentali. I VCS ti consentono di essere più audace con le modifiche proposte senza rompere il codice sorgente del progetto principale. I sistemi DVCS e VCS standard si avvicinano in modo molto diverso: uno di questi funzionerà meglio per il tuo team.
• Come si installano e si configurano i server?
• Hai bisogno di autenticazione? In tal caso, come fai ad assicurarti che solo le persone autorizzate ad apportare modifiche possano effettivamente farlo?

Alla fine, fai una rapida valutazione per determinare se i sistemi VCS o DVCS standard saranno i migliori per il tuo team. Dovrai scegliere lo strumento che fornisce la minima quantità di dolore o probabilmente non verrà adottato. Successivamente, valuta le tue alternative che meglio soddisfano le tue esigenze.

Alla fine, impara cosa intendi usare.

Penso che molte persone trovino git più complicato di svn perché è diverso. Dopo aver usato la sovversione (o cvs, ecc.) Per un po ', può essere difficile cambiare mentalmente le modalità in un modello DVCS. Sulla base di ciò, direi che potrebbe essere una buona idea ricercare il VCS tradizionale come la sovversione insieme alla ricerca di un DVCS come Git.

Sebbene git sia il mio VCS preferito, direi che probabilmente è meglio imparare anche la sovversione. Per prima cosa, ci sono ancora molti repository di sovversione e cvs là fuori che potresti dover interagire un giorno, e avrai anche una migliore comprensione dei precisi vantaggi e svantaggi del DVCS rispetto ai VCS tradizionali.

Sarebbe controproducente imparare svn e poi git

Ecco alcuni motivi:

• Gits radicalmente diverso da svn. Git è in dubbio e svn è client / server.
• Diversi significati sono associati alle stesse parole. Ad esempio 'git checkout ...' ha un significato diverso da 'svn checkout ...'
• La ramificazione è diversa. Git ha questo concetto di rami 'topic' che sono rami locali economici che svn non supporta.
• Git ha un posto in più, chiamato indice, che si trova tra l'albero di lavoro e il tuo repository. Svn non ha indice. Usando git le tue modifiche si spostano dall'albero di lavoro all'indice al repository.

Il mio consiglio è di imparare semplicemente Git.

Ci sono alcune cose sostanzialmente uguali in GIT e SVN e altre no.

Creazione / aggiornamento / checkout / commit

In generale, dovresti prenderlo facilmente.

come taggare e ramificare ma ancora molto confuso su conflitti tra rami e tronco ecc

Differente tra i due.

Non dicendo che dovresti o non dovresti cambiare ora (penso che sia la tua chiamata), volevo solo sottolineare che è qualcosa da prendere in considerazione. Se sei sicuro di voler provare Git, puoi decidere di passare ora per salvare te stesso mentre impari qualcosa in SVN diverso in Git.

Wow; 12 risposte e tutti stanno ancora chiedendo la domanda ...

No, Subversion non è un prerequisito per Git.

Non esiste una mappatura pulita tra Subversion e Git: se hai intenzione di imparare entrambi, dovrai solo soffrire per il fatto che usano gli stessi termini per azioni diverse. (E termini diversi per le stesse azioni.)

• svn commitè una cosa diversa da git commit.
• i rami in svn e git sono molto diversi
• un repository svn è più simile a un git remote (ma non proprio)
• un repository git è più simile a una copia di lavoro svn (ma non proprio)

Questi sono due strumenti divisi per un linguaggio comune.

La tua domanda, e la maggior parte delle altre risposte, presumono che git sia una specie di svn ++; Un "svn migliore". Non lo è. I due sono strumenti diversi che lavorano nello stesso spazio, come un'auto e una moto.

Suggerirei di sceglierne uno, padroneggiarlo e iniziare a usarlo nella tua squadra. Il controllo della versione di apprendimento sarà difficile per le persone che non lo hanno mai usato prima. Il tuo VCS sarà una parte importante della tua infrastruttura e imparare a fidarti implica la costruzione di nuove abitudini di lavoro. Ci vuole un po '.

(Ad ogni modo, assicurati di avere i tuoi amministratori di sistema di backup nel repository principale - perdere il controllo del codice sorgente sarebbe catastrofico.)

Probabilmente no - ci sono sufficienti differenze tra server basati e distribuiti che probabilmente ti confonderesti ulteriormente.

Inizia fin dall'inizio per seguire le buone pratiche con il DVCS di tua scelta come da zero e probabilmente sarai molto più felice.

Guarda Mercurial (se non vuoi essere sopraffatto).

Git è solo leggermente più complicato di Subversion, perché esiste una distinzione in Git tra il commit e il push al repository centrale.

Vale la pena imparare Git mentre hai la possibilità di distrarre la mente da Subversion.

Non credo sia necessario capire Subversion per capire Git.

La differenza più grande con Git e Mercurial di Subversion, almeno per me, è che hai un repository locale con cui lavori, esegui il check-in e il check-out fino a quando il codice non funziona, fai il checkout dal repository centrale, risolvi eventuali conflitti e ricontrollare e spingere sul server.

Mi piace molto git in ambiente Unix (Linux, MacOS X). In Windows, è un po 'confuso. Considererei Mercurial se avessi Windows nell'equazione.

Mi sono piaciute le tue lezioni di storia, prova SCCS, RCS, CVS, Subversion e poi usa qualcosa di utile come Git o Mercurial.

Git e Mercurial sono equipotenti, il grande vantaggio di Git è github . Ma se non vuoi esternalizzare il controllo della tua versione, github non è più nell'equazione.

I sistemi di controllo della versione condividono qualcosa in comune con i linguaggi di programmazione in quanto il primo che impari impiegherà più tempo. Successivamente, raccoglierne uno nuovo è solo una questione di apprendimento di come i concetti fondamentali sono espressi dal nuovo sistema.

Puoi imparare Git ora e dedicare tempo all'apprendimento della Suvbersion in seguito, se necessario.

No. Scarica Git, crea un account github e scherza per un paio di giorni facendo il repository, ecc. Git è piuttosto banale con cui metterti al passo. Impara 5 o 6 comandi bash e puoi svolgere tutte le attività essenziali. In genere preferisco la "resistenza agli idioti" di una GUI, ma Git Bash è più semplice che mai. Inoltre, Git Gui è abbastanza decente se preferisci quella rotta. Non vedo davvero il beneficio che vedresti dall'apprendimento di SVN. Ho attraversato un periodo di tempo fa in cui stavo valutando alcuni diversi sistemi di controllo versione per un nuovo progetto open source. Ho provato SVN, Bazaar, Git e un paio di altri e ho imparato le basi di ciascuno. YMMV, ma Git era di gran lunga il più semplice. Non c'è nulla di sbagliato nell'apprendimento di SVN, ma in realtà non ti aiuterà a imparare Git.