Estratégias de branchs

Olá Léo, tudo bem com você? Espero que sim.

Peço desculpa pela demora em responder o seu tópico.

Isso pode variar de desenvolvedor(a) para desenvolvedor(a) ou de empresa para empresa, que poderá possuir políticas claras em relação à exclusão de uma branch que foi mergiada.

Uma vantagem de excluir essas ramificações consiste na facilidade de localização das branchs dentro do projeto assim mantendo um padrão de qualidade, ordem e evitando um repositório superlotado de branchs. Já a desvantagem de realizar essa exclusão após o merge é se caso em algum momento for necessário fazer mais alterações na branch e não termos o acesso a ela. Portanto, nessas situações, a exclusão deve ser feita caso tenha certeza que não terá mais fluxo de trabalho nela.

Um detalhe importante a se ressaltar é que no mercado de trabalho, geralmente segue-se um padrão do Git Flow, que consiste em um modelo de fluxo de trabalho, onde vamos trabalhar com duas branchs principais, a Develop e a Master, que vão estar presentes durante todo o projeto, e outras 3 branchs secundárias, a Feature, a Release e o Hotfix, que diferente das anteriores vão ser temporárias e serão excluídas quando for realizado um merge para as branchs principais.

Em resumo, para trabalhos pequenos que não estamos trabalhando em equipe, para evitar um número desnecessário e excessivo de branchs, é uma boa prática apagá-las após o merge, em contrapartida, ao trabalhar em equipe, é interessante que se defina previamente uma política a ser seguida nesses casos, não tem uma fórmula mágica.

Caso queira se aprofundar neste assunto e conhecer mais sobre uma dessas políticas de trabalho, recomendo um artigo da Alura que aborda sobre o ecossistema de trabalho do Git Flow:

• Git Flow: entenda o que é, como e quando utilizar

Espero que eu tenha lhe ajudado de alguma forma, caso tenha mais alguma dúvida vou estar a sua disposição. Abraços e bons estudos!