Sono esattamente in questa situazione ma ho optato per un flusso di lavoro leggermente più complesso ma non necessariamente più complicato con Git.
All'inizio l'obiettivo era imparare la git così quindi ho esplorato un po '. poi è tornato praticamente al flusso di lavoro che hai descritto.
Dopo un po 'è diventato difficile lavorare con il verificarsi di alcune situazioni e mi ha dato cattive abitudini che sarebbero state difficili da spezzare una volta entrato in una squadra.
così ho optato per il seguente:
- Deposito locale per lavorare.
- Ramo principale come trunk stabile per l'applicazione
- Un ramo per ogni caratteristica / refactor, in sostanza un ramo per ogni cambiamento considerevole che verrà fatto.
- Unire nuovamente al tronco quando il ramo è stabile e tutti i test passano.
Ho anche impostato un account git hub in cui sincronizzo il trunk. Questo mi ha permesso di iniziare facilmente a lavorare su diversi computer. Era per necessità, ma mi ha permesso di trovare bug che erano legati all'ambiente in cui mi trovavo e che non erano disponibili sugli altri computer. Quindi ora ho l'abitudine di provare almeno una volta un progetto su un diverso sistema "vergine". Mi risparmia un sacco di mal di testa quando arriva il momento di distribuire al cliente.
- Taggo tutte le versioni che lo trasformano in github come versione rilasciabile.
- Se rilasciato al cliente, partirò da questa versione per creare un secondo trunk stabile per le correzioni di bug dichiarate dal cliente.
Inizialmente i molteplici rami sembravano eccessivi, ma REALMENTE ha aiutato molto. Potrei iniziare un'idea in un ramo, lavorarci per un po 'e quando comincio a correre i circoli ho rinunciato e ho iniziato un altro ramo per lavorare su qualcos'altro. Più tardi mi è venuta l'idea di tornare al ramo mezzo cotto ed esplorare questa idea. questo nel complesso mi ha reso MOLTO più produttivo in quanto ho potuto agire rapidamente su flash e idee e vedere se funzionava. Il costo del cambio di filiali con GIT è estremamente basso, il che 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 di averne davvero bisogno. L'ho spinto come "bello da imparare".
Quando tutte le ramificazioni sono diventate complicate, ho esplorato l'opzione di registro per disegnare un albero di modifiche e vedere quale ramo sono dove.
Per farla breve, git non è come SVN, CVS o (brrr) TFS. La ramificazione è molto economica e fare errori che spazzano via il lavoro è in realtà piuttosto difficile. Solo una volta ho perso un po 'di lavoro ed è stato perché ho fatto i miei impegni troppo grandi (vedi sopra le cattive abitudini). Se ti impegni spesso, con piccoli pezzi git sarà sicuramente il tuo miglior alleato.
Per me git mi ha aperto la mente su cosa sia veramente il controllo del codice sorgente. Qualcos'altro prima era solo tentativi di ottenerlo, Git è il primo, che nella mia mente, capito. Detto questo, non ho provato altri DVCS, molto probabilmente questa affermazione potrebbe essere ampliata a tutta la famiglia.
Un ultimo consiglio, la riga di comando è il tuo amico. Per non dire che gli strumenti grafici non sono buoni, anzi, al contrario, ma mi sono davvero imbrogliato 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 aiuto molto completo. Il mio più grande problema era legato alla ma brutta console di Windows fino a quando non ho trovato alternative.
Ora utilizzo entrambi, l'integrazione 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 gli alberi di registro più 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 sul mio codice sorgente.
Buona fortuna, spero che questo abbia aiutato.