Eu o uso para manutenção crítica de sites. Sou o único desenvolvedor, mas tenho um mestre, desenvolvo e emito ramos.
Meu processo de trabalho para a configuração do site é semelhante a este:
Tornar o ramo mestre viável. Faça o commit inicial.
Caixa desenvolver filial. Não faça nada, desenvolva funções como um buffer de teste para mesclar no master.
Ramo de emissão do Google Checkout. Codifique seu problema, quando estiver pronto, desenvolva-o, veja se há algum problema, mescla conflitos etc ... conserte-os.
Quando problemas suficientes são mesclados no desenvolvimento para uma liberação e o desenvolvimento foi testado quanto à estabilidade, puxe o item para o mestre.
Master
|
Develop - E
/ | \ \
A B C D
Dessa forma, você obtém uma coleção completa de testes em desenvolvimento, onde é possível testar a estabilidade, os problemas, etc ... sem correr o risco de prejudicar o Master e reverter os commits se eles forem prejudiciais.
Além disso, usando ramificações individuais para confirmação, você pode "deixar" o trabalho que já fez, começar de novo em outra coisa para corrigir um problema mais urgente e distribuí-lo mais cedo.
Na vida real, normalmente tenho um ramo de questões, e puxo esse para o desenvolvimento e depois para o mestre. Às vezes é entediante, mas a cada dois meses pelo menos eu tenho que largar o trabalho com um chapéu, porque alguém teve uma idéia de que eu tenho que criar o RightNow ™ e dessa maneira eu posso voltar rapidamente ao estado base, fazer a coisa e depois continuar onde eu estava. Especialmente em grandes projetos que levam várias semanas, esse é um grande incentivo para que eu possa trocar rapidamente de ramo.
Considere este cenário: Você sempre trabalhar em um ramo principal e você tem AwesomeCodeThing ™ nas obras que deixa o seu ramo Mestre em cirurgia de coração aberto e uma YugeBug ™ aparece que precisa de conserto urgente de outra forma milhares de usuários vai reclamar com você sobre BigProblems ™
A única maneira de resolver rapidamente seu problema nesse cenário,
- verifique suas confirmações anteriores,
- ver quando foi o seu último commit estável (a maldição é opcional)
- reverter para esse commit
- fazer reparo, enviar reparo para produção
- resolva todos os conflitos e problemas que você está tentando recuperar ao status AwesomeCodeThing ™
- desistir, chorar e começar a trabalhar. (opcional)
Se você usar ramos:
- Mestre do Google Checkout
- criar ramo UrgentFix ™ e consertar coisas
- puxe o UrgentFix ™ para o mestre
- empurrar para a produção
- Mesclar mestre para desenvolver
- Mesclar o desenvolvimento no AwesomeCodeThing ™
- pegue uma cerveja e continue trabalhando.