Estou exatamente nessa situação, mas optei por um fluxo de trabalho um pouco mais complexo, embora não necessariamente mais complicado, com o Git.
O objetivo, a princípio, era aprender o caminho do git, então eu explorei bastante. depois, revertida para praticamente o fluxo de trabalho que você descreveu.
Depois de um tempo, tornou-se difícil trabalhar com isso, pois algumas situações surgiram e me deram maus hábitos que seriam difíceis de romper quando eu ingressasse em uma equipe.
então decidi pelo seguinte:
- Repositório local para trabalhar.
- Ramo mestre como tronco estável para a aplicação
- Uma ramificação para cada recurso / refator, basicamente uma ramificação para cada alteração considerável que será feita.
- Volte ao tronco quando o ramo estiver estável e todos os testes forem aprovados.
Também configuro uma conta do git hub na qual sincronizo o tronco. Isso me permitiu começar a trabalhar facilmente em computadores diferentes. Foi por necessidade, mas me permitiu encontrar bugs vinculados ao ambiente em que eu estava e que não estava disponível nos outros computadores. Então agora eu tenho o hábito de tentar um projeto em um sistema "virgem" diferente pelo menos uma vez. Economiza muitas dores de cabeça quando chega a hora de implantar no cliente.
- Eu codifico todas as versões que o fazem no github como uma versão liberável.
- Se liberado para o cliente, vou ramificar a partir desta versão para criar um segundo tronco estável para correções de erros declaradas pelo cliente.
Os vários ramos a princípio pareciam um exagero, mas REALMENTE ajudou muito. Eu poderia começar uma idéia em um ramo, trabalhar nele por um tempo e, quando começo a correr círculos, desisti e comecei outro ramo para trabalhar em outra coisa. Mais tarde, surgiu uma idéia em que eu voltava ao ramo meio cozido e explorava essa idéia. isso me deixou muito mais produtivo, pois pude agir rapidamente com flashes e idéias e ver se funcionava. O custo da troca de ramificações com o GIT é extremamente baixo, tornando-me muito ágil com minha base de código. Dito isto, ainda tenho que dominar o conceito de rebase para limpar minha história, mas como estou sozinho, duvido que realmente precise. Empurrou como "bom aprender".
Quando toda a ramificação se tornou complicada, explorei a opção de log para desenhar uma árvore de alterações e ver qual ramificação estava onde.
Para encurtar a história, o git não é como SVN, CVS ou (brrr) TFS. Ramificar é muito barato e cometer erros que acabam com o trabalho é realmente muito difícil. Apenas uma vez eu perdi algum trabalho e foi porque fiz meus compromissos muito grandes (veja maus hábitos acima). Se você se comprometer com frequência, em pequenos pedaços, o git será definitivamente o seu melhor aliado.
Para mim, o git abriu minha mente para o que realmente é o controle de origem. Qualquer outra coisa antes era apenas uma tentativa de obtê-lo, o git é o primeiro, que em minha mente, o entendi. Dito isto, eu não tentei outros DVCS, muito possivelmente essa declaração poderia ser ampliada para toda a família.
Um último conselho, a linha de comando é seu amigo. Para não dizer que as ferramentas gráficas não são boas, muito pelo contrário, mas eu realmente gostei do git quando desci para a linha de comando e tentei fazer isso sozinho. Na verdade, é muito bem feito, fácil de seguir com um sistema de ajuda muito abrangente. Meu maior problema foi estar vinculado ao console feio do Windows até encontrar alternativas.
Agora eu uso os dois, a integração do Eclipse com o Git para ver o que está acontecendo em tempo real e fazer algumas operações como diffs, explorar o histórico de um arquivo etc. . alguns scripts básicos e nunca fui tão produtivo com relação ao controle de origem e nunca tive tanto controle sobre minha fonte.
Boa sorte, esperava que isso ajudasse.