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.