git per progetti personali (one-man). Eccessivo?

Conosco e utilizzo due sistemi di controllo della versione: Subversion e git. Subversion, fin d'ora, viene utilizzato per progetti personali in cui sono l'unico sviluppatore e git viene utilizzato per progetti e progetti open source in cui credo che anche altri lavoreranno sul progetto. Ciò è dovuto principalmente alle incredibili capacità di fork e fusione di git, in cui tutti possono lavorare sul proprio ramo; molto maneggevole.

Ora uso Subversion per progetti personali, poiché penso che git abbia poco senso lì. Sembra essere un po 'eccessivo. Va bene per me se è centralizzato (sul mio server di casa, di solito) quando sono l'unico sviluppatore; Prendo comunque backup regolari. Non ho bisogno della capacità di creare il mio ramo, il ramo principale è il mio ramo. Sì, SVN ha un supporto semplice per le ramificazioni, ma credo che un supporto molto più potente non abbia senso. La fusione può essere un dolore, o almeno dalla mia piccola esperienza.

C'è qualche buona ragione per usare git su progetti personali o è semplicemente eccessivo?

Non è eccessivo. Il motivo principale per cui ho iniziato a utilizzare Git e Mercurial su Subversion per progetti personali è che l'avvio di un repository è molto più semplice.

Vuoi iniziare un nuovo progetto?

> git init

BAM! Non è necessario configurare un server di repository né archiviare una struttura di cartelle per supportare la ramificazione e i tag in un repository di sovversione.

La condivisione del progetto in un secondo momento è solo una questione di: git push(oltre ad avere un repository remoto). Prova a farlo rapidamente con sovversione!

Direi che usare Subversion per progetti personali locali è eccessivo, mentre Git decisamente no. Git occuperà meno spazio (a causa dell'inefficiente concetto di "revisioni" di SVN rispetto alle istantanee degli oggetti di Git), richiede meno installazione ( git initrispetto a una dozzina di svnadmincomandi e impostazioni di autorizzazioni e così via), è più facile eseguire il backup ( git clone --bare[o git push originse usi Github o simili] e il gioco è fatto) e dispone di strumenti migliori per la gestione del codice (la ramificazione è gratuita e l'unione è più semplice e pulita). Solo perché nessun altro ha un clone del tuo repository non significa che i vantaggi di qualsiasi DVCS siano "eccessivi".

Inoltre, direi che il supporto delle ramificazioni di Git è meno complesso di quello di SVN, con maggiori ricompense.

Pensare che non diramerai mai il tuo codice è un po 'miope. Ho ramificato il mio codice diverse volte, in particolare quando stavo sperimentando un nuovo approccio di cui non ero ancora del tutto convinto. Alla fine vorrai la funzione.

Questo viene da un utente Subversion da molto tempo. Il consolidamento su uno strumento può davvero aiutarti a semplificarti la vita.

Overkill è riservato quando si verificano danni collaterali causati dalla "soluzione". Usare una pistola per uccidere una mosca significa che ci sono danni causati dal proiettile che va altrove. È eccessivo. L'uso di qualcosa di più potente del necessario che non causa problemi non è eccessivo e può essere una buona cosa se ti aiuta a semplificare il processo di sviluppo. Non provoca alcun danno e consente di aggiornare solo un set di software anziché due. Quindi perché preoccuparsi di due sistemi invece di uno?

Uso Git per i miei progetti personali e lo adoro. In precedenza utilizzavo Subversion e non ho ancora visto un aspetto negativo nell'utilizzo di Git. È più potente ma non in un modo che rende le cose semplici più complicate. Rendere le cose semplici inutilmente complicate / costose / lente / ecc. IMHO è una condizione necessaria per chiamare qualcosa di eccessivo. Inoltre, su Github ho biforcuto progetti precedentemente personali di altre persone per aggiungere una funzione che volevo e poi ho inviato loro richieste pull. Lo troverei abbastanza interessante se qualcuno interessato ai miei progetti facesse la stessa cosa.

Non ho mai usato il controllo del codice sorgente su progetti personali prima di DVCS, quindi è un po 'strano immaginare che qualcuno abbia la visione opposta. Alcuni dei miei motivi sono:

• Facile da installare e demolire. Ad esempio, un collega mi ha dato un puzzle di programmazione la settimana scorsa che ho risolto in diversi piccoli passaggi. Ho fatto un repository git che è durato tutti i 45 minuti per contenere il mio lavoro, e poi è sparito. Non so quanto sia facile qualcosa di simile in sovversione, ma non ho mai sentito parlare di nessuno.
• Disconnected. Per me, essere in grado di lavorare offline è molto più un vantaggio per un progetto di hobby che uno per lavoro. Non ho bisogno di creare un buco nel mio firewall di casa o ospitare pubblicamente un progetto. Posso temporaneamente mettere un repository su una chiavetta USB o un laptop e mantenere tutto sincronizzato.
• Tutto colocato. Avere il repository e l'albero di lavoro insieme rende più facile tenere traccia dei piccoli progetti durante gli aggiornamenti del sistema operativo.
• Funzionalità potenti. Certo, non ho bisogno del potere tutto il tempo, ma è lì quando ne ho bisogno e non consuma risorse quando non lo faccio.

Mi è stato detto che git-bisectè davvero bello per trovare il commit esatto che ha introdotto un determinato comportamento, navigando avanti e indietro nei commit a seconda del tuo input.

Si dovrà avere a che fare che un giorno per le cose che semplicemente non può capire cosa è successo.

EDIT: Inoltre, la capacità di ramificare è molto importante quando devi fare correzioni di bug nelle vecchie versioni che i clienti usano. Devi essere in grado di gestire "basta riparare questa piccola cosa ma non voglio la versione più recente perché non voglio testarla di nuovo ora".

Dipende da quanto seriamente vuoi ottenere il controllo delle versioni del tuo codice. Se quello che stai costruendo è ad esempio una semplice libreria che avrà sempre e solo la versione corrente (o per tutto il tempo che è vero), personalmente utilizzerei solo un'opzione di backup di base come Dropbox. Se perdi tutto il tuo codice, puoi recuperarlo dal Web e Dropbox ha un backup della versione di 30 giorni se fai davvero qualcosa di stupido.

Tuttavia, se ad esempio hai bisogno di mantenere i rami Production e Dev, allora git è assolutamente un ottimo strumento e un diavolo molto più veloce di svn. Tieni presente il rischio di guasti del disco rigido se, tuttavia, memorizzi i dati solo localmente.

Userei sempre, sempre, sempre un sistema di controllo della versione per qualsiasi tipo di progetto di sviluppo. Grandi o piccoli non contano davvero. Sia che io stia giocando a casa con una sorta di nuova tecnologia, scrivendo un piccolo aiuto per facilitare la mia vita o sviluppando professionalmente in una squadra grande e distribuita, vorrei sempre un sistema di controllo della versione per supportarmi.

Certo, la maggior parte delle volte per piccoli progetti personali non userete la maggior parte delle funzionalità, ma impostare un repository git (o anche un repository Subversion locale) non è un grosso problema, quindi provatelo! E prima che tu lo sappia vorrai sapere "accidenti, qual era il contenuto del file X venerdì scorso?". Senza controllo della versione - buona fortuna ;-)

Quindi, non importa se usi git o SVN - personalmente sto iniziando a migrare sempre più cose da SVN a git, ma la cosa principale è usare il controllo della versione, anche per le piccole cose.

Solo perché nessuno lo ha menzionato: per i progetti personali, darcs è davvero buono e meno coinvolto di git per fare un controllo diretto della versione. Non è così veloce per i progetti più grandi, ma nemmeno Subversion!

Può essere un potente cambio di paradigma mentale per capire che ciò che facciamo è la sperimentazione. Avere uno strumento economico / facile per supportare questo, migliora la tua capacità di andare avanti, in parte perché migliora la tua capacità di uscire da qualsiasi esperimento quando risulta male.

Molti sviluppatori dicono: Beh, faccio solo copie del mio codice. Ma queste copie diventano difficili da gestire e finiscono per essere disordinate. Hai più copie e non ricordi quale copia di cosa, quindi prova a capire quando è sicuro eliminarle.

Tutto ciò diventa ancora più prezioso quando l'esperimento comporta cambiamenti coordinati su più file. E quando si tratta di un progetto solista, usare Git diventa ancora più semplice.

Invece di chiedermi se dovrei usarlo in un progetto solista, ora penso che peccato non averlo scoperto prima.