Immagina di avere un amico al telefono (non VoIP) che chiede: "Cosa c'è di così speciale in Git? Sto bene usando Subversion." Quale sarebbe il tuo "elevator pitch" per descrivere il vantaggio dell'uso di un DVCS come Git?Elevator pitch per Git a/o DVCS
Per me, una delle cose principali che si possono fare in un DVCS come git che non funziona bene in SVN è la seguente:
1) Creare diversi rami di sviluppo fuori del tronco per le varie funzioni che sono in fase di sviluppo.
2) Unisci codice da un ramo di funzione in un altro ramo di funzione prima che il ramo di funzione sia terminato e pronto per essere unito nel tronco.
3) Successivamente, unire i rami feature nel trunk.
È bello suddividere le nuove funzionalità in rami separati in modo che il tronco rimanga pulito fino al termine delle funzioni. Ma, inevitabilmente, ti imbatti in una situazione in cui un team che lavora su un ramo di funzionalità ha scritto un codice che è necessario da un team su un altro ramo di funzionalità. Se unisci questo codice tra i rami di funzionalità con SVN, non avrai più problemi a unire il tronco in seguito. Git evita questo problema.
Ecco un altro vantaggio ... La tua azienda decide di esternalizzare lo sviluppo di una funzionalità per una società appaltante indiana.Oppure, il tuo gruppo di servizi professionali deve aggiungere una funzionalità per un cliente e tale funzione potrebbe essere prodotta in futuro. Davvero non vuoi dare accesso in scrittura al tuo SVN al contraente indiano o al tuo gruppo PS. Quindi, devono compilare il codice al di fuori del controllo del codice sorgente e devi fonderlo in te stesso, rilevare e risolvere autonomamente eventuali conflitti senza alcun aiuto da parte di SVN e perdere tutta la cronologia del check-in degli appaltatori nel processo.
Ma con git, basta dare all'appaltatore o al gruppo PS una copia del repository e possono impegnarsi a farlo proprio come uno sviluppatore. Successivamente, puoi utilizzare le funzionalità di git per unire le modifiche nel tuo repository git. Git troverà i conflitti e conserverà la storia.
Infine, una delle cose più interessanti di git è che non devi davvero convincere il tuo amico che è meglio di SVN. Poiché git si integra perfettamente con SVN, la tua azienda/amico può tranquillamente usare SVN mentre tu usi felicemente un git collegato a SVN.
Due parole: unione, ramificazione.
L'unione e la ramificazione sono più facili in Git che in qualsiasi altro. Git aveva bisogno di risolvere un problema: unire codice scritto da migliaia di sviluppatori che raramente hanno la stessa revisione. Ora provate questo in SVN:
Può essere eseguito con SVN ma in Git, questa è la modalità di funzionamento predefinita e, quindi, la più semplice.
Penso che l'affermazione "in Git, questo è l'impostazione predefinita" non è chiara. Cosa è "questo" in questa affermazione? –
Sei sicuro di "M & B è più semplice in SVN che in Git"? –
Sciocco. Fisso. –
Chiedere a lui di lavorare/checkout/commit/controllare i registri/ripristinare senza accesso al suo repository di rete (ad esempio su un piano).
Questo è citato ogni volta che le persone parlano di revisione distribuita, ma onestamente, quanti * sviluppatori * lavorano sugli aerei? – JasonSmith
Lavoro sui treni quasi ogni giorno. – Dustin
Conosco un ragazzo che lavora in un villaggio in Africa e contribuisce al kernel di Linux e a molti altri progetti open source. Il suo unico accesso a Internet è un Internet café in una città a 3 ore di distanza, e quel caffè apre solo un'ora alla settimana. Ubiquitous Internet Access è un mito. –
C'era già a question similar to this. Inoltre, Eric Sink aveva uno number di articles su DVCS. Entrambe le risposte alle altre domande e agli articoli possono aiutare a costruire una decisione informata. Dire semplicemente che uno è meglio dell'altro probabilmente non aiuterà (purtroppo, sembra essere tutto ciò che Linus fa al riguardo, il che non aiuta veramente a convincere le persone, almeno non me :)).
È un problema di blub.
Tutto ciò che puoi fare nel tuo sistema centralizzato, posso farlo nel mio sistema distribuito, ma le mie attività giornaliere DVCS che mi rendono uno sviluppatore incredibilmente efficiente non possono essere eseguite nel tuo sistema centralizzato - e non puoi capirlo perché percepisci il mondo con le limitazioni che il tuo sistema ha posto su di te.
Per uno sviluppatore, la differenza più importante tra DVCS e SVN è la velocità .
Quando un comando che impiega 30 secondi o 4 minuti in SVN impiega invece 1 o 2 secondi in Git o Mercurial o Bazaar, è un'enorme differenza per uno sviluppatore. Il controllo della versione diventa un'attività secondaria anziché un'interruzione del flusso di lavoro. Non è necessario aggiungere caffeina & ri-invocare il rituale pavloviano per mettersi al lavoro; tieni la tua attenzione non perderla.
Altri benefici sono importanti, ma sono secondarie al confronto:
solito piantare gli ascensori per 90 nodi velocità rispetto all'aria, quindi controllare il mio glidepath con l'acceleratore. Oltre la soglia, estendi i flap se sei sicuro di non avere ghiaccio, quindi gira a ritroso e arrotondati di circa un piede da terra ... Mi dispiace, sito web sbagliato. –
Il mio telefono funziona raramente nell'ascensore. – Damo