Come unico sviluppatore (per ora), come dovrei usare Git? [chiuso]

54

Ho diversi progetti su Git che alla fine voglio coinvolgere. Comunque, al momento sono solo io e uso Git e GitHub in modo molto semplicistico: niente branch e fondamentalmente solo l'uso dei commit come backup dei miei file locali. A volte tornerò indietro e guarderò le versioni precedenti dei miei file come riferimento, ma non ho avuto bisogno di fare alcun rollback fino a questo punto, anche se apprezzo l'opzione se ne avessi bisogno in futuro.

Come unico sviluppatore, quali funzionalità di Git o GitHub potrei trarre vantaggio mi avvantaggerebbero in questo momento? Come dovrebbe essere il mio flusso di lavoro?

Inoltre, ci sono delle pratiche particolari che devo iniziare a fare in previsione di aggiungere altre ai miei progetti in futuro?

    
posta VirtuosiMedia 13.10.2011 - 22:55
fonte

4 risposte

58

Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future?

Naturalmente. C'è una semplice buona pratica che puoi usare anche se non hai una squadra in questo momento: crea un ramo separato per lo sviluppo. L'idea è che il ramo master conterrà solo versioni di codice rilasciate o modifiche importanti. Questo può essere facilmente adottato dai nuovi sviluppatori che aderiscono al tuo progetto.

Inoltre, la ramificazione è utile anche se lavori da solo. Ad esempio, si trova un bug mentre si sta codificando una nuova funzione. Se non si utilizzano i rami, sarà necessario eseguire entrambe le operazioni: aggiungere nuove funzionalità e correggere il bug nello stesso ramo. Questo non va bene: P D'altra parte, se hai creato un nuovo ramo per la creazione della tua nuova funzione, puoi semplicemente controllare il ramo di sviluppo, correggere il bug e ricontrollare il nuovo ramo di funzionalità.

Questo è solo un breve esempio di cosa puoi fare come unico programmatore. Sono sicuro che ci devono essere più buone pratiche.

Ti consiglio vivamente questo articolo: Un modello di branching Git riuscito

    
risposta data 13.10.2011 - 23:27
fonte
13

Sono esattamente in questa situazione, ma ho optato per un flusso di lavoro leggermente più complesso ma non necessariamente più complicato con Git.

L'obiettivo in un primo momento è stato imparare il modo git così ho fatto un po 'di esplorazione. quindi è tornato praticamente al flusso di lavoro che hai descritto.

Dopo un po 'è diventato difficile lavorare con alcune situazioni, inoltre mi hanno dato cattive abitudini che sarebbero state difficili da rompere una volta entrato in squadra.

quindi ho scelto:

  • repository locale per il lavoro.
  • Ramo principale come tronco stabile per l'applicazione
  • Un ramo per ogni feature / refactor, fondamentalmente un ramo per ogni cambiamento considerevole che verrà fatto.
  • Unisci di nuovo al tronco quando il ramo è stabile e tutti i test passano.

Ho anche configurato un account git hub dove sincronizzo il trunk. Questo mi ha permesso di iniziare facilmente a lavorare su computer diversi. Era per necessità, ma mi permetteva di trovare bug legati all'ambiente in cui non ero disponibile sugli altri computer. Quindi ora ho l'abitudine di provare un progetto su un sistema "vergine" diverso almeno una volta. Mi risparmia un sacco di mal di testa quando arriva il momento di distribuire al cliente.

  • Contrassegno ogni versione che lo rende in github come versione rilasciabile.
  • Se rilasciato al cliente, si diramerà da questa versione per creare un secondo tronco stabile per correzioni di bug dichiarate dal cliente.

I vari rami all'inizio sembravano eccessivi, ma DAVVERO ha aiutato molto. Potrei iniziare un'idea in un ramo, lavorarci sopra per un po 'e quando avrò iniziato a girare cerchi mi sono arreso e ho iniziato un altro ramo per lavorare su qualcos'altro. Più tardi arrivò un'idea in cui tornavo al ramo mezzo cotto ed esplora questa idea. questo complesso mi ha reso MOLTO più produttivo in quanto ho potuto agire con flash e idee molto rapidamente e vedere se ha funzionato. Il costo del cambio di filiale con GIT è estremamente basso e mi rende molto agile con la mia base di codice. Detto questo, devo ancora padroneggiare il concetto di rebase per ripulire la mia storia, ma dato che sono tutto solo, dubito che ne abbia davvero bisogno. Spinto come "bello da imparare".

Quando tutte le diramazioni si sono complicate, ho esplorato l'opzione di registro per disegnare un albero di modifiche e vedere in quale ramo si trova.

Per farla breve, git non è come SVN, CVS o (brrr) TFS. Branching è molto economico e fare errori che spazzerà via il lavoro è in realtà piuttosto difficile. Solo una volta ho perso un po 'di lavoro ed è stato perché ho reso i miei commit troppo grandi (vedi cattive abitudini sopra). Se ti impegni spesso, da piccoli pezzi git sarà definitivamente il tuo miglior alleato.

Per me, ho aperto la mente a quale sia il vero controllo del codice sorgente. Qualcos'altro prima era solo un tentativo di ottenerlo, git è il primo, che nella mia mente, l'ho capito. Detto questo, non ho provato altri DVCS, probabilmente questa affermazione potrebbe essere estesa a tutta la famiglia.

Un ultimo consiglio, la riga di comando è tuo amico. Per non dire che gli strumenti grafici non sono buoni, anzi, al contrario, mi sono davvero divertito quando sono passato alla riga di comando e l'ho provato da solo. In realtà è molto ben fatto, facile da seguire con un sistema di guida molto completo. Il mio più grande problema era essere legato alla console, ma brutta in Windows fino a quando ho trovato alternative.

Ora uso entrambe le integrazioni di Eclipse con Git per vedere cosa sta succedendo in tempo reale e fare alcune operazioni come diff, esplorare la cronologia di un file, ecc. E la riga di comando per ramificare, unire, spingere, ottenere e tanto altro alberi di tronchi complessi. alcuni script di base e non sono mai stato così produttivo per quanto riguarda il controllo del codice sorgente e non ho mai avuto così tanto controllo sulla mia fonte.

Buona fortuna, spero che questo sia stato di aiuto.

    
risposta data 14.10.2011 - 04:01
fonte
4

Sono esperto in diversi sofisticati modelli di branching e ne utilizzo alcuni al lavoro. Tuttavia, quando lavoro da solo sui progetti, faccio praticamente esattamente quello che stai facendo ora. Posso sempre creare un ramo dopo il fatto se ne ho bisogno, ma non lo faccio quasi mai. Lavorando da solo, raramente ho correzioni di bug che non possono aspettare fino a quando il mio compito attuale è finito. Il mio consiglio è di avere familiarità con alcuni modelli di ramificazione, ma non ha senso complicare le cose fino a quando non è necessario.

    
risposta data 14.10.2011 - 01:58
fonte
2

Per un modello più semplice, puoi vedere cosa fa GitHub. "GitHub flow" è molto semplice, e qui c'è un'eccellente guida: link

Riepilogo (dal blog di Scott Chacon ):

So, what is GitHub Flow?

  • Anything in the master branch is deployable
  • To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
  • Commit to that branch locally and regularly push your work to the same named branch on the server
  • When you need feedback or help, or you think the branch is ready for merging, open a pull request
  • After someone else has reviewed and signed off on the feature, you can merge it into master
  • Once it is merged and pushed to ‘master’, you can and should deploy immediately
    
risposta data 07.08.2014 - 13:22
fonte

Leggi altre domande sui tag