Resumindo: a melhor prática é ramificar, mesclar com frequência e manter sempre sincronizado .
Existem convenções bem claras sobre como manter seu código em ramificações separadas da ramificação principal:
- Você está prestes a fazer uma implementação de mudanças importantes ou disruptivas
- Você está prestes a fazer algumas alterações que podem não ser usadas
- Você deseja experimentar algo que não tem certeza de que funcionará
- Quando você é instruído a se ramificar, outras pessoas podem ter algo que precisam fazer no mestre
Como regra geral, após a ramificação, você deve manter a sincronização com a ramificação principal. Porque, eventualmente, você precisa mesclá-lo de volta ao mestre. Para evitar uma bagunça enorme e complicada de conflitos ao mesclar novamente, você deve confirmar frequentemente, mesclar com frequência.
Boas práticas a seguir
Um modelo de ramificação Git bem-sucedido de Vincent Driessen tem boas sugestões. Se este modelo de ramificação lhe interessar, considere a extensão do fluxo para git . Outros comentaram sobre o fluxo .
Práticas de marcação
Como você já sabe, o Git fornece a você identificadores de confirmação como 1.0-2-g1ab3183, mas esses 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 descreve cria. Em outras palavras, no Git você não codifica ramos. Você está marcando confirmações. É correto dizer que a tag é apenas um ponteiro anotado para uma confirmação.
Vamos olhar para o exemplo prático que o demonstrou,
/ - [v1.0]
v
---. ---. --- .--- S ---.--- A <- mestre
\
\ -.--- B <- teste
Vamos confirmar 'S' ser confirmado, apontado pela tag 'v1.0'. Essa confirmação está na ramificação 'master' e na ramificação 'test'. Se você executar " git description " no topo do commit 'A' (no topo do ramo 'master'), obterá algo como v1.0-2-g9c116e9
. Se você rodar "git description" em cima do commit 'A' (também conhecido como ramificação 'test'), você obterá algo como v1.0-2-g3f55e41
, esse é o caso da configuração padrão do git-description. Observe que esse resultado é um pouco diferente. v1.0-2-g9c116e9
significa que estamos no commit com o ID SHA-1 classificado 9c116e9
, 2 confirma após o tag v1.0
. Não há etiqueta 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, atualizar apenas as informações da versão padrão / fallback em GIT-VERSION-FILE) após o ponto de ramificação da ramificação 'test'. Se você marcar commits no ramo 'test' com, por exemplo, 'v1.0.3`, isso seria visível apenas em' test '.
Referências
Encontrei muitos blogs e posts úteis para aprender. No entanto, os que são ilustrados profissionalmente são raros. Portanto, eu gostaria de recomendar um post - Um modelo de ramificação Git bem-sucedido por @nvie. Eu emprestei sua ilustração :)