Quais são as vantagens de usar a ramificação como um desenvolvedor solo?

As vantagens são praticamente as mesmas que para grupos de desenvolvedores. Usando uma ramificação mestre sempre pronta para o lançamento e ramificações de recursos para o desenvolvimento de novos recursos, você sempre pode liberar o mestre. Encontre um bug importante ao trabalhar em um recurso? Alterne o ramo, corrija, solte, volte e continue a desenvolver.

Ou talvez este seja um projeto de hobby e você goste de poder trabalhar um pouco sobre esse recurso e um pouco disso, conforme o clima o surpreender. Você basicamente está emulando uma equipe de várias pessoas dividindo o tempo.

A ramificação implícita que os DVCSs fazem nos clones significa que as ramificações formais no repositório autoritativo são menos sobre a coordenação de pessoas e mais sobre a coordenação de direções de desenvolvimento, e até uma única pessoa pode fazer várias delas.

Desenvolvimento de longa duração

A ramificação para uma equipe de uma única pessoa seria útil para um recurso de desenvolvimento de longa duração que, de outra forma, não se ajusta ao seu ciclo de lançamento.

Você pode obter uma ramificação para sua alteração de abrangência de vários meses e ainda conseguir enviar correções de bugs ou alterações diárias de sua ramificação principal em intervalos regulares.

Isso tem a vantagem sobre 'switches' em uma única ramificação em que sua ramificação principal está sempre em um estado implantável e você tem a garantia de que nada no recurso de longa execução teve um impacto em outro código testado anteriormente.

Funcionalidades experimentais

Uma ramificação também pode ser útil para recursos que você pode querer prototipar, mas que podem nunca chegar ao seu código implantado. Completar isso em um ramo no qual meu último ser jogado fora significa que você nunca polui sua base de código principal desnecessariamente.

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:

1. Crie uma ramificação mestre viável. Fazer commit inicial.

2. Verifica a ramificação do desenvolvimento. Não faça nada, desenvolva funções como um buffer de teste para mesclar no mestre.

3. 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,

1. verifique seus commits anteriores,
2. veja quando seu último commit estável foi (amaldiçoar é opcional)
3. reverter para esse commit
4. conserte, envie para a produção
5. resolva todos os conflitos e problemas que você está tentando recuperar para o status AwesomeCodeThing ™
6. desista, chore e comece a trabalhar. (opcional)

Se você usa ramificações:

1. Mestre de check-out
2. crie o branch UrgentFix ™ e corrija as coisas
3. puxe o UrgentFix ™ para o master
4. empurrar para produção
5. Mesclar mestre para desenvolver
6. Mesclar desenvolver em AwesomeCodeThing ™
7. tome uma cerveja e continue trabalhando.

Os ramos facilitam o trabalho em vários recursos de uma só vez, o que pode ser bastante útil quando as prioridades mudam durante o andamento de um projeto.

Digamos que você decida que um recurso é mais importante agora. Talvez você precise corrigir urgentemente um bug crítico em um sistema ativo. Você pode estar trabalhando com um cliente em vários recursos por um longo período de tempo e pode querer demonstrar o progresso de cada recurso separadamente. Talvez você tenha acabado de ler sobre uma exploração desagradável do dia zero e queira entrar nela antes que o cliente leia sobre isso.

Se você estiver usando ramificações para cada recurso / hotfix, normalmente será mais fácil, mais limpo e mais rápido isolar e implantar essas modificações, em vez de usar uma única ramificação para tudo. Isso vale se você é um desenvolvedor único ou parte de uma equipe.

Quanto a um processo real, acho que o fluxo do git funciona bem. A folha de dicas de fluxo do git de Daniel Kummer é um ótimo recurso, vale a pena olhar mesmo se você não estiver usando o git .

Como mencionado por outros pôsteres, as vantagens são substancialmente semelhantes ao trabalho em equipe: a capacidade de desenvolver e testar recursos de maneira independente, manter um ramo mestre separado para hotfixes / implantações de produção, experimentar.

Para mim, pessoalmente, eu geralmente tento trabalhar em master se eu conheço a área em que estou trabalhando muito bem, apenas adiciona overhead à ramificação porque eu só vou mesclar de qualquer maneira.

No entanto, se eu tiver qualquer hesitação sobre as alterações que estou fazendo, irei ramificar e somente PR / mesclar uma vez que a ramificação se comporta como esperado e é geralmente totalmente testada. Dessa forma, se eu descobrir um problema para o qual reverter é o melhor curso de ação, é um único commit em vez de uma série inteira (nunca me lembro da sintaxe para reverter uma série de commits, mas um único é fácil). / p>