Por que devo usar tags vs. branches de lançamento / beta para controle de versão?

114

Estou usando o git por cerca de um ano e gostaria de usar tagging para, bem, marcar commits em diferentes versões. Encontrei muitas informações sobre os comandos a serem usados para trabalhar com tags, mas o que eu gostaria de saber é por que usar tagging se eu posso apenas criar um novo branch chamado 1.1.0e não tenho que turvar minha mente com um todo novo conjunto de comandos git?

Deve haver uma série de boas razões para etiquetar em vez de ramificar, mas gostaria de saber quais são essas vantagens.

git branch git-tag

— wufoo
fonte

96

As tags são usadas principalmente para referência futura à versão específica do projeto, marcando um commit. Você sempre pode usar branches, é claro, mas se você mudar muito as versões, vai acabar com muitos branches não usados ou raramente usados.

Praticamente, as tags são ramos sem ramos de qualquer maneira, apenas adicionando uma forma de referenciar uma versão específica do projeto para reduzir a complexidade.

Edit: Esta é uma boa maneira de usar o git que uso para todos os meus projetos.

— Hakan Deryal
fonte

Heh (: É realmente um ótimo fluxo de trabalho que cobre todas as soluções possíveis.

— Hakan Deryal

sim, já vi o método nvie antes e fiquei bastante confuso com ele. No entanto, pretendo implementá-lo assim que o compreender. Acho que com uma tag, você não pode alterar acidentalmente o código, confirmar e ainda estar com a mesma versão. Com ramos, pode acontecer inadvertidamente. As tags parecem ser uma forma mais segura de marcar lançamentos.

— wufoo de

2

A beleza do método nvie para mim é que não precisei entendê-lo inicialmente. Eu poderia apenas encontrar a seção para o que eu queria fazer e digitar os comandos. Depois de algumas vezes, tornou-se natural e em poucos dias eu estava dançando em volta dos galhos como um profissional!

— Killroy 01 de

Esperar entender a abordagem do gitflow apenas aplicando-o cegamente fará com que você perca todas as simplificações que poderia aplicar a ele para sua situação. E o gitflow é de fato impróprio para a maioria das equipes: ou excessivamente complexo ou excessivamente simples.

— toolforger

151

Uma tag é imutável .

Considerando que você pode criar um branch chamado "1.0.0" - você, ou qualquer pessoa com direitos de commit, também pode simplesmente enviar para aquele branch (deliberadamente ou não) e mudar o que 1.0.0 significa.

Você não pode fazer isso com uma tag, uma vez que você cria uma tag - é isso; Tag 1.0.0 significa exatamente isso e não pode ser alterado ^* .

Essa é a principal diferença prática entre uma tag e um branch

^* Você pode excluir e recriar uma tag, alterando-a, mas certamente não por acidente.

— AD7six
fonte

18

Costumo usar um fluxo de trabalho que incorpora tags e branches. As tags são boas para marcar código lançado ou construções de desenvolvimento notáveis. Ramificações são boas para controlar todas as mudanças relevantes a uma versão específica.

Aqui está um bom artigo sobre esse tipo de fluxo de trabalho: http://nvie.com/posts/a-successful-git-branching-model/

— Justin ᚅᚔᚈᚄᚒᚔ
fonte

18

Branch e tag são a mesma coisa (ponteiro para um commit, também conhecido como "ref" ), exceto que o branch se move automaticamente para o próximo commit, enquanto a tag permanece ¹ para sempre no mesmo commit.

Ao fazer uma versão, geralmente você deseja marcar o "instantâneo" do código a partir do qual essa versão foi construída e deseja que ele permaneça marcado dessa forma, mesmo enquanto continua a evoluir o código, para usar uma tag.

Se você tentar usar um branch para isso, pode inadvertidamente mover para um commit diferente, do qual a versão não foi construída.

¹ A menos que você exclua a tag, é claro.

NOTA: Sei que esta é uma pergunta antiga, mas senti que a semelhança (e uma diferença crucial) entre branches e tags não foi concretizada em outras respostas tão claramente como poderia ter sido.

— Branko Dimitrijevic
fonte

Caro @downvoter, algum motivo específico para o downvote?

— Branko Dimitrijevic

Eu não votei contra sua resposta, mas o que você quer dizer com “branch move automaticamente para o próximo commit”? Ramificações não se movem automaticamente para nenhum commit. Executar git commitatualiza o cabeçalho do branch em check-out para fazer referência ao novo commit, sim, mas nenhum outro branch se move “automaticamente” para o próximo commit. Você deve esclarecer o primeiro parágrafo de sua resposta.

— Escova de dentes

1

@Escova de dentes Claro, é isso que eu quis dizer com "se move automaticamente". No entanto, o branch realmente não "possui" nenhum commit, ele nem mesmo aponta para um conjunto de commits, ele apenas aponta para um commit (e o resto pode estar implícito, às vezes imprecisamente, percorrendo o gráfico de commit). No git, branch é apenas um arquivo de uma linha .git\refs\heads, contendo o hash do commit. Os próprios compromissos não "lembram" qual branch os criou. Isso é diferente do Mercurial, por exemplo, onde as informações do branch podem ser escritas nos metadados do commit.

— Branko Dimitrijevic

Sim, mas muitas pessoas não sabem disso - especialmente os recém-chegados que estão confusos sobre a miríade de maneiras que são sugeridas online de fazer as coisas com o Git.

— Escova de dentes de

6

Você usa tags para anotar commits importantes na história. "Este foi o commit exato que usamos para esta versão naquela quinta-feira chuvosa quando o servidor de compilação quebrou". Se você usar um branch ao invés de uma tag, você nunca saberá qual commit exato você usou. Você só sabe "Lançamos a versão 1.1.0 em algum lugar deste branch", a menos que anote manualmente o hash exato para esse commit, que é o motivo pelo qual você usa tags em primeiro lugar :)

— Ralphtheninja
fonte

4

Acho que ele quis dizer criar um branch chamado 1.1.0 e não usá-lo mais, então ele representará o projeto na versão nomeada.

— Hakan Deryal

2

Além das outras respostas, aqui estão meus 2 centavos.

Resposta curta: Use tags para versões de lançamento

Resposta longa: Eu acredito que usar tags para versão de lançamento especificamente é melhor do que usar branches. Se você precisar atualizar o relase, simplesmente ramifique o commit marcado e uma vez que você terminar de trabalhar naquele branch (provavelmente um branch de hotfix), crie uma nova tag no cabeçalho desse novo branch com a nova versão. Em seguida, mescle esse branch de volta em master / development porque você realmente não deve alterar uma versão de lançamento, a menos que seja um hotfix que provavelmente deva ser mesclado de volta ao seu código-fonte. Em seguida, exclua esse branch, pois ele não é mais necessário. Se você precisar aplicar outro hotfix a essa nova versão, repita as mesmas etapas.

Consulte a seção do artigo a seguir que mostra como mesclar um hotfix com o fluxo de trabalho Git do autor - https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2

— Região 39
fonte