Eu o uso para manutenção crítica de sites. Eu sou o único desenvolvedor ainda tenho um mestre, desenvolver e emitir ramos.
Meu processo de trabalho para a configuração do site é assim:
-
Crie uma ramificação mestre viável. Fazer commit inicial.
-
Verifica a ramificação do desenvolvimento. Não faça nada, desenvolva funções como um buffer de teste para mesclar no mestre.
-
Verifica o ramo de problemas. Codifique seu problema, quando estiver pronto, desenvolva-o, veja se algum problema surge, mescle conflitos, etc ... corrija-os.
Quando problemas suficientes são mesclados no desenvolvimento de um lançamento e o desenvolvimento é testado quanto à estabilidade, puxe o desenvolvimento para mestre.
Master
|
Develop - E
/ | \ \
A B C D
Dessa forma, você obtém uma coleção completa de testes no desenvolvimento, onde é possível testar a estabilidade, problemas, etc., sem ter que se arriscar a prejudicar o Mestre e ter que reverter os commits se eles forem prejudiciais.
Além disso, ao usar ramificações individuais para confirmar, você pode "sair" do trabalho que já fez, começar de novo em outra coisa para corrigir um problema mais urgente e implementá-lo mais cedo.
Na vida real eu geralmente tenho um ramo de problemas, e puxo aquele em desenvolvimento e depois em mestre. Às vezes é tedioso, mas uma vez a cada dois meses, pelo menos, eu tenho que desistir do trabalho, porque alguém teve uma idéia que eu tenho que fazer RightNow ™ e dessa forma eu posso voltar rapidamente para um estado básico, fazer a coisa e depois continue onde eu estava. Especialmente em grandes projetos que demoram várias semanas, este é um godsent que eu posso mudar rapidamente de ramificações.
Considere este cenário: Você trabalha sempre em um ramo principal e tem AwesomeCodeThing ™ nos trabalhos que deixam sua filial Master em cirurgia de coração aberto e um YugeBug ™ que precisa de conserto urgente, caso contrário, milhares de usuários irão reclamar com você sobre BigProblems ™
A única maneira de resolver seu problema rapidamente em um cenário como esse,
- verifique seus commits anteriores,
- veja quando seu último commit estável foi (amaldiçoar é opcional)
- reverter para esse commit
- conserte, envie para a produção
- resolva todos os conflitos e problemas que você está tentando recuperar para o status AwesomeCodeThing ™
- desista, chore e comece a trabalhar. (opcional)
Se você usa ramificações:
- Mestre de check-out
- crie o branch UrgentFix ™ e corrija as coisas
- puxe o UrgentFix ™ para o master
- empurrar para produção
- Mesclar mestre para desenvolver
- Mesclar desenvolver em AwesomeCodeThing ™
- tome uma cerveja e continue trabalhando.