Resumindo: A prática recomendada é expandir, mesclar com frequência e manter sempre em sincronia .

Existem convenções bem claras sobre como manter seu código em ramificações separadas do branch master:

1. Você está prestes a implementar uma mudança importante ou perturbadora
2. Você está prestes a fazer algumas alterações que talvez não sejam usadas
3. Você quer experimentar algo que não tem certeza de que funcionará
4. Quando você é solicitado a ramificar-se, outros podem ter algo que precisam fazer no mestre

Regra geral é depois de ramificar, você deve manter em sincronia com o ramo mestre. Porque eventualmente você precisa mesclar de volta ao master. Para evitar uma enorme e complicada confusão de conflitos ao mesclar de volta, você deve cometer frequentemente, mesclar com frequência.

Boas práticas a seguir

Um modelo bem-sucedido de ramificação do Git por Vincent Driessen boas sugestões. Se esse modelo de ramificação agrada a você, considere a extensão de fluxo . Outros têm comentados sobre o fluxo .

Práticas de marcação

Como você já sabe, o Git lhe dá identificadores de commit como 1.0-2-g1ab3183, mas eles não são tags! A marcação é feita com a tag git e as tags criadas usando a tag git são a base para os identificadores de confirmação que o git describe cria. Em outras palavras, no Git você não marca ramificações. Você está marcando commits. É correto dizer que tag é apenas um ponteiro anotado para uma confirmação.

Vamos ver um exemplo prático que demonstrou isso,

                        /-- [v1.0]
                       v
---.---.---.---S---.---A     <-- master
                         \ 
                           \-.---B     <-- test

Vamos confirmar que 'S' seja commit apontado pela tag 'v1.0'. Este commit é tanto no branch 'master' quanto no branch 'test'. Se você executar " git describe " no topo do commit 'A' (topo do branch 'master') você obteria algo como v1.0-2-g9c116e9 . Se você executar "git describe" no topo do commit 'A' (também conhecido como branch 'test'), você obterá algo como v1.0-2-g3f55e41 , que é o caso da configuração git-describe padrão. Note que este resultado é um pouco diferente. v1.0-2-g9c116e9 significa que estamos em commit com ID SHA-1 classificado de 9c116e9 , 2 confirmações após a tag v1.0 . Não há tag v1.0-2 !

Se você deseja que sua tag apareça apenas na ramificação 'master', é possível criar uma nova confirmação (por exemplo, apenas atualizar informações de versão padrão / de fallback no GIT-VERSION-FILE) após o ponto de ramificação da ramificação 'test'. Se você marcar as confirmações na ramificação "teste" com, por exemplo, 'v1.0.3' seria visível apenas a partir de 'teste'.

Referências

Encontrei muitos, muitos blogs e postagens úteis para aprender. No entanto, aqueles que são ilustrados profissionalmente são raros. Assim, eu gostaria de recomendar um post - Um modelo de ramificação Git bem-sucedido por @nvie. Eu pedi emprestado sua ilustração:)

Uma ramificação é usada se você tiver duas versões diferentes do repositório ao mesmo tempo. Uma tag é uma maneira de marcar um ponto no tempo em seu repositório.

Você deve adicionar uma tag para marcar uma versão lançada. Se você precisar fazer correções de bugs para essa versão, você criaria uma ramificação na tag.

Você só deseja excluir as ramificações que foram mescladas de volta ao HEAD [ou alguma outra ramificação].