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 em primeiro lugar foi aprender o caminho certo, então eu explorei um pouco. em seguida, reverteu para praticamente o fluxo de trabalho que você descreveu.
Depois de um tempo isso se tornou difícil de trabalhar, pois algumas situações surgiram também me deu maus hábitos que seriam difíceis de quebrar quando eu me juntasse a um time.
então resolvi o seguinte:
- Repositório local para trabalhar.
- Filial principal como um tronco estável para o aplicativo
- Um ramo para cada recurso / refatorador, basicamente um ramo para cada alteração considerável que será feita.
- Mesclar de volta ao tronco quando a ramificação estiver estável e todos os testes passarem.
Eu também configuro uma conta do hub git onde sincronizo o tronco. Isso me permitiu começar a trabalhar facilmente em computadores diferentes. Foi por necessidade, mas permitiu-me encontrar bugs que estavam ligados ao ambiente que eu estava em 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. Me poupa muitas dores de cabeça quando chega a hora de implantar para o cliente.
- Eu marquei todas as versões que fazem isso no github como uma versão liberável.
- Se liberado para o cliente, ramificará desta versão para criar um segundo tronco estável para correções de bugs declaradas pelo cliente.
Os vários ramos no início pareciam um exagero, mas realmente ajudou muito. Eu poderia começar uma ideia em um ramo, trabalhar nela por um tempo e quando eu começar a rodar círculos eu desisti e comecei outro ramo para trabalhar em outra coisa. Mais tarde, surgiu uma ideia em que eu voltava para o ramo meio assado e explorava essa ideia. No geral, isso me tornou MUITO mais produtivo, já que eu conseguia fazer flashes e idéias muito rapidamente e ver se funcionava. O custo de trocar de agências com o GIT é extremamente baixo, o que me torna muito ágil com minha base de código. Dito isso eu ainda tenho que dominar o conceito rebase para limpar a minha história, mas desde que eu estou sozinho eu duvido que eu 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 em qual ramificação está o local.
Longa história curta, git não é como SVN, CVS ou (brrr) TFS. A ramificação é muito barata e cometer erros que acabam com o trabalho é realmente muito difícil. Apenas uma vez eu perdi algum trabalho e foi porque eu fiz meus commits muito grandes (veja os maus hábitos acima). Se você cometer muitas vezes, por pequenos pedaços, definitivamente será seu melhor aliado.
Para mim, abri minha mente para o que realmente é o controle de origem. Qualquer outra coisa antes era apenas tentativas de consegui-lo, git é o primeiro, que na minha mente, entendi. Dito isto, eu não tentei outros DVCS, possivelmente essa declaração poderia ser ampliada para toda a família.
Um último conselho, a linha de comando é seu amigo. Não quer dizer que as ferramentas gráficas não são boas, muito pelo contrário, mas eu realmente geei git quando caí na linha de comando e tentei por mim mesmo. É realmente muito bem feito, fácil de seguir com um sistema de ajuda muito abrangente. Meu maior problema estava sendo amarrado ao console, mas feio no Windows até que eu encontrei alternativas.
Agora eu uso os dois, integração do Eclipse com o Git para ver o que está acontecendo em tempo real e fazer algumas operações como diffs, explorar histórico para um arquivo, etc. E linha de comando para ramificação, fusão, envio, obtenção e mais árvores de toras complexas. alguns scripts básicos e eu nunca fui tão produtivo no que diz respeito ao controle de fonte e nunca tive tanto controle sobre minha fonte.
Boa sorte, esperamos que isso tenha ajudado.