Resumindo: A prática recomendada é ramificar, mesclar frequentemente e manter sempre em sincronia .

Existem convenções bastante claras sobre como manter seu código em ramos separados do ramo mestre:

1. Você está prestes a fazer uma implementação de uma mudança importante ou disruptiva
2. Você está prestes para fazer algumas alterações que podem não ser usadas
3. Você deseja experimentar algo que não tem certeza se funcionará
4. Quando lhe é dito para ramificar, outras pessoas podem ter algo que precisam fazer no mestre

A regra é após a ramificação, você deve manter a sincronia com o mestre filial. Porque, eventualmente, você precisa mesclá-lo de volta ao master. Para evitar uma grande e complicada confusão de conflitos ao mesclar novamente, você deve se comprometer frequentemente, mesclar frequentemente.

Boas práticas a serem seguidas

Um modelo de ramificação Git bem-sucedido de Vincent Driessen tem boas sugestões. Se este modelo de ramificação agrada a você, considere a extensão de fluxo para git . Outros comentaram sobre o fluxo .

Práticas de marcação

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

Vejamos um exemplo prático que o demonstrou,

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

Deixe “s commit” S “ser o commit apontado pela tag” v1.0 “. Este commit está no branch “master” e no branch “test”. Se você executar " git describe " além do commit ” Um “(topo do branch” master “) você obteria algo como v1.0-2-g9c116e9. Se você executar " git describe " no topo do commit “B” (também conhecido como branch “test”), você obterá algo como v1.0-2-g3f55e41, que é o caso com a configuração git-describe padrão. Observe que esse resultado é um pouco diferente. v1.0-2-g9c116e9 significa que estamos no commit com o id SHA-1 ordenado de 9c116e9, 2 commits após a tag v1.0. Não há tag v1.0-2!

Se você quiser que sua tag apareça apenas no branch “master”, você pode criar um novo commit (por exemplo, apenas atualizar o padrão / fallback informações de versão em GIT-VERSION-FILE) após o ponto de ramificação da ramificação “teste”. Se você marcar commits no branch “test” com, por exemplo, “v1.0.3` seria visível apenas em” test “.

Referências

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

Comentários

• 1.0-2-g1ab3183 é um identificador construído por git describe a partir das informações disponíveis no git, mas chamá-lo de identificador git é um pouco demais. O Git identifica por hash SHA; tags e branches são construções humanas que o git mantém o controle de forma útil. Como tal, faça uma tag quando você pensa que algum humano um dia desejará encontrar um marcador conveniente para um commit.
• uma ilustração maravilhosa de multidimensionalidade no universo git. lindo. obrigado
• Vale a pena observando que muitos projetos não precisam de alguns das pistas mostradas neste diagrama. Alguns projetos precisam apenas do que ' s chamados de desenvolver e apresentar aqui. Isso geralmente é verdade para aplicativos da web que podem ser implantados à vontade.
• Até mesmo o autor do fluxo git não o recomenda mais para muitos tipos de projeto, como desenvolvimento da web. Muitas pessoas acreditam que é muito mais complexo do que a grande maioria dos projetos precisa, tornando-o difícil de executar e fácil de errar.No outro extremo do espectro, alguns profissionais avançados defendem que equipes usam ' desenvolvimento baseado em tronco ', que quase nunca usa ramos, e entregar projetos de sucesso como esse. Para algo intermediário, considere " anti-gitflow '

Um branch é usado se você tiver 2 versões diferentes do repositório ao mesmo tempo. Uma tag é uma forma 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ê deve criar um branch na tag.

Você só deseja excluir branches que foram mesclados de volta no HEAD [ou algum outro branch].

Comentários

• oh … e suponho que você quer dizer que o branch é mesclado com outro branch, como master. HEAD se move toda vez que eu faço uma verificação, certo?
• HEAD geralmente aponta para um branch (a menos que você ' esteja no modo HEAD separado), então HEAD se move com o ramo para o qual aponta