No

Git è così radicalmente diverso da SVN che non ti aiuterà. Semmai cercherete comandi di "aggiornamento" e "commit" e vi chiedete perché tutto è diverso.

Inizia con Git from the Bottom Up e vai da lì.

Contrastare un sistema di controllo standard delle versioni di aggiornamento / commit centralizzato con Git è come confrontare un autobus con il trasporto di massa. Un autobus ti porterà (e tutti gli altri) dal punto A al punto B utilizzando lo stesso percorso. Il trasporto di massa ti porterà dal punto A al punto B utilizzando qualsiasi percorso tu voglia.

Distribuito ha degli svantaggi di cui dovresti essere a conoscenza. Ci vuole più lavoro per mantenere tutti sulla stessa pagina. Tuttavia offre un enorme aumento di flessibilità.

Revisione hash e numeri

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

In primo luogo raramente (se mai) hai bisogno di trattare direttamente con gli hash in commit / pull giornalieri. È necessario aprire il registro e tirare gli hash se si stanno facendo diffs o alcuni degli elementi di riordino più complicati.

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

No, per favore non disturbarti nemmeno.

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

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

Potresti anche essere interessato a leggere questa altra domanda: Sono un disadattato di Subversion, perché dovrei considerare o non considerare Mercurial o Git o altri DVCS?

Scelta tra DVCS

Personalmente, uso sia mercurial che git, e penso che sia importante conoscerli entrambi. Una lettura consigliata su questo argomento è Git vs. Mercurial: per favore rilassati (vedi il git -addremove esempio). Due citazioni da quell'articolo che penso riassumano.

Per quanto riguarda git:

Git’s design philosophy is unmistakably that of Unix: unlike Subversion, CVS, or Mercurial, git is not one monolithic binary but a multitude of individual tools, ranging from high-level “porcelain” commands such as git-pull, git-merge, and git-checkout to low-level “plumbing” commands such as git-apply, git-hash-object and git-merge-file. So, like MacGyver, you can do just about anything you need with Git – this includes totally awesome Wiki engines, issue trackers, filesystems, sysadmin tools – everything short of fuse repair.

Per quanto riguarda il mercurial:

Developers who like to keep their system clean will probably appreciate the fact that hg installs one binary in contrast to the 144 that make up git, and developers who think that git’s ability to edit your previous commits is moronic, unnecessary, and dangerous will appreciate the simplicity hg provides by omitting that particular feature.

Un sacco di 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 (equivalente di github per mercurial).

La mia raccomandazione: inizia con mercurial e non appena ti senti a tuo agio con esso, prendi git; non si tratta degli strumenti, ma delle persone con cui lavori .

Quello che considero l'uso reale e pratico della sovversione è, 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 (indirizzabile in git e hg ora, però). svn up e il tuo progetto e le sue dipendenze vengono aggiornati.

Citando Thorbjørn su questo altro thread :

DVCSes are to Subversion, what Bittorrent is to ftp

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

Dovresti imparare quello che intendi usare. Git è popolare, proprio come Mercurial ha anche 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 della versione sia considerato un nuovo argomento per troppi team), aiuta a delineare i propri obiettivi e i criteri di valutazione. Non devi essere super-formale, ma poni le seguenti domande:

• Qual è lo scopo del controllo della versione nel nostro team. Sì, tutti i sistemi di controllo delle versioni che valgono qualcosa ti permetteranno di tornare indietro nella storia e vedere cosa è cambiato in un dato file. Tuttavia, hai intenzione di usarlo per le nuove versioni di base? (annuisci con la testa, vuoi questo). Questa è la dichiarazione della visione in 2-3 linee per ciò che si vuole ottenere.
• La tua squadra era abituata ad avere il proprio ambiente di lavoro locale solo per unire le cose con attenzione in seguito? Se è così, la rotta DVCS potrebbe avere più senso.
• Al contrario, il tuo team è abituato a lavorare da un'unità condivisa e tutto è in costante integrazione? Se è così, il VCS più tradizionale potrebbe avere più senso.

Quando valuti le tue alternative, devi considerare le cose importanti che tutti i VCS devono fare:

• Codice di riferimento (rami taggati, etichette, ecc.). In sostanza, come si ottiene il codice sorgente esatto utilizzato in una versione del proprio progetto.
• Ottieni modifiche locali al server centrale. È necessaria una copia autorevole del codice, indipendentemente dal fatto che si utilizzi DVCS o VCS standard. Ogni strumento tratta questo processo in modo diverso.
• Ottieni le modifiche nel server centrale alla tua copia locale.
• Come gestire i cambiamenti sperimentali. VCS ti permettono 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 configuri e configuri i server?
• Hai bisogno di autenticazione? In tal caso, come fai a essere sicuro che solo le persone a cui è consentito apportare modifiche possano effettivamente

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 minor quantità di dolore o che probabilmente non verrà adottato. Successivamente, valuta le alternative che meglio si adattano alle tue esigenze.

Alla fine, impara cosa intendi usare.

Penso che molte persone trovino git più complicato di svn perché è diverso. Dopo aver usato subversion (o cvs, ecc.) Per un po ', può essere difficile cambiare mentalmente le modalità in un modello DVCS. Basandomi su questo, direi che potrebbe essere necessario per cercare VCS tradizionali come la sovversione in tandem con la ricerca di un git simile a DVCS.

Sebbene git sia il mio VCS preferito, direi che probabilmente è meglio anche imparare la sovversione. Per uno, ci sono ancora molti repository di subversion e cvs che potrebbero essere necessari per interagire con un giorno, e inoltre avrai una migliore comprensione dei vantaggi e degli svantaggi precisi di DVCS rispetto ai tradizionali VCS.

Sarebbe controproducente imparare svn e poi git

Ecco alcuni motivi:

• Gits radicalmente diversi da svn. Git è distrubted e svn è client / server.
• I significati diversi 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 "argomento" che sono rami locali economici che svn non supporta.
• Git ha un posto aggiuntivo, chiamato indice, che si trova tra l'albero di lavoro e il tuo repository. Svn non ha indice. Usando git le tue modifiche passano dalla tua struttura di lavoro all'indice al repository.

Il mio consiglio è solo di imparare git.

Ci sono alcune cose in generale le stesse in GIT e SVN e altre no.

Create/update/checkout/commit

In linea di massima, dovresti prenderlo facilmente.

how to tag and branch but still confused a lot about conflicts between branches and trunk etc

Diversi tra i due.

Non dire che dovresti o non dovresti cambiare ora (penso che sia la tua chiamata), volevo solo indicarlo perché è qualcosa da tenere in considerazione. Se sei sicuro di voler provare Git, potresti decidere di passare ora per risparmiare te stesso imparando qualcosa in SVN che è diverso in Git.

Wow; 12 risposte e tutti stanno ancora elemosinando 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 diverse azioni. (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 da una lingua comune.

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

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

(In ogni caso, assicurati di avere il tuo amministratore di sistema di backup del repository principale - perdere il controllo del codice sorgente sarebbe catastrofico.)

Probabilmente no - ci sono differenze sufficienti tra il server basato e distribuito che probabilmente ti confonderei ulteriormente.

Parti dall'inizio per seguire le buone pratiche con il DVCS di tua scelta come se fosse tutto da capo e probabilmente sarai molto più felice.

Dai un'occhiata a Mercurial (se non vuoi essere travolto)

Git è solo marginalmente più complicato di Subversion, perché c'è una distinzione in Git tra commit e push al repository centrale.

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

Non credo che la comprensione di Subversion sia necessaria per capire Git.

La più grande differenza con Git e Mercurial da Subversion, almeno per me, è che hai un repository locale con cui lavori, controlli dentro e fuori da lì finché il tuo codice non funziona, checkout dal repository centrale, fix eventuali conflitti e ricontrolla e spinga al server.

Mi piace molto git nell'ambiente Unix (Linux, MacOS X). In Windows, è un po 'hacky. Prenderò in considerazione Mercurial se avrò Windows nell'equazione.

Mi sono piaciute le tue classi di storia, prova SCCS, RCS, CVS, Subversion e poi uso qualche cosa utile come Git o Mercurial.

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

I sistemi di controllo delle versioni condividono qualcosa in comune con i linguaggi di programmazione in quanto il primo che impari richiederà più tempo. Dopo di che, prenderne uno nuovo è solo questione di imparare come i concetti principali sono espressi dal nuovo sistema.

Puoi imparare Git adesso e investire tempo nell'apprendimento di Suvbersion più tardi, se necessario.

No. Scarica Git, crea un account github e gingilla per un paio di giorni a forgiare i repository, ecc. Git è piuttosto banale per essere aggiornato. Impara 5 o 6 comandi bash e puoi svolgere tutte le attività essenziali. Generalmente preferisco la "sicurezza dell'idiota" di una GUI, ma Git Bash è tanto facile quanto basta. Inoltre, Git Gui è abbastanza decente se preferisci quella via. Non vedo davvero il vantaggio che vedresti nell'apprendimento di SVN. Ho passato un periodo di tempo in cui stavo valutando alcuni sistemi di controllo versione per un nuovo progetto open source. Ho provato SVN, Bazaar, Git e un altro paio e ho imparato le basi di ciascuno. YMMV, ma Git era di gran lunga il più semplice. Non c'è niente di sbagliato nell'apprendimento di SVN, ma in realtà non ti aiuterà a imparare Git.