Quando excluir ramificações no Git?

Suponha que tenhamos um aplicativo estável.

Amanhã, alguém relata um grande problema que decidimos corrigir imediatamente. Portanto, criamos uma ramificação para esse hotfix fora de "master", o denominamos "2011_Hotfix" e o empurramos para que todos os desenvolvedores possam colaborar na correção.

Corrigimos o erro e mesclamos "2011_Hotfix" em "master" e também no ramo de desenvolvimento atual. E pressione "mestre".

O que fazemos com o "2011_Hotfix" agora? Deveria permanecer ali como um ramo para sempre até o fim dos tempos ou devemos excluí-lo agora, pois serviu a seu propósito? Parece impuro deixar galhos espalhados por toda parte, pois a lista de galhos provavelmente se tornará muito longa, a maioria dos quais nem é mais necessária.

No caso de ser excluído, o que acontecerá com seu histórico? Isso será mantido, mesmo que a ramificação real não esteja mais disponível? Além disso, como removeria uma ramificação remota?

Você pode remover com segurança um ramo com git branch -d yourbranch. Se ele contiver alterações não imersas (ou seja, você perderá os commit excluindo o branch), o git dirá a você e não o excluirá.

Portanto, excluir uma ramificação mesclada é barato e não fará com que você perca nenhum histórico.

Para excluir uma ramificação remota, use git push origin :mybranch, assumindo que seu nome remoto seja origem e a ramificação remota que você deseja excluir seja nomeada mybranch.

O que você precisa fazer é marcar qualquer coisa que você liberar. Mantenha os ramos por perto para quando você estiver desenvolvendo ativamente.

Exclua ramificações antigas com

git branch -d branch_name

Exclua-os do servidor com

git push origin --delete branch_name

ou a sintaxe antiga

git push origin :branch_name

que lê como "enviar nada para branch_name na origem".

Dito isto, enquanto o DAG (gráfico acíclico direcionado) puder apontar para ele, os commits estarão lá na história.

O Google "git-flow" e isso podem fornecer mais informações sobre gerenciamento de liberação, ramificação e marcação.

Como a pergunta tem a tag "github", eu também adicionaria isso: especificamente no Github , se você solicitar uma ramificação e ela for mesclada (por meio da interface do usuário ou mesclando a ramificação da solicitação), você não perca os dados da solicitação de recebimento (incluindo comentários), mesmo se você remover a ramificação .

Uma conseqüência disso: se você incorporar solicitações pull como parte do seu fluxo de trabalho (que combina suavemente com as revisões de código), poderá excluir com segurança as ramificações assim que elas forem mescladas. Isso é tão comum que recentemente o Github adicionou um recurso (doce) que exibe um botão "excluir ramificação" logo após a mesclagem de uma solicitação pull.

Mas é importante notar que cada grupo deve adotar o fluxo de trabalho que melhor lhe convém (e pode ou não levar à exclusão de tais ramificações). Minha equipe de trabalho atual, por exemplo, remove todas as ramificações que não são mestre ou relacionadas à implantação (por exemplo, produção, preparo etc.) assim que suas solicitações pull são mescladas, e ainda temos um rastreamento completo de como as confirmações relacionadas foram formadas cada melhoria incremental de cada produto.

É claro que nenhum gerenciamento de histórico (solicitações de recebimento ou de outra forma) substitui a marcação adequada de versões (que você prefere automatizar com a mesma ferramenta / script que implanta / empacota uma versão), para que você possa sempre alternar rapidamente para o que seus usuários estiverem em um determinado momento. A marcação também é a chave para resolver seu problema original: se você estabelecer que qualquer ramificação mesclada com as ramificações "de trabalho" pode e deve ser excluída e que qualquer que seja mesclada com uma tag de versão, "produção" etc. , você sempre terá os hotfixes ativos até que sejam integrados em uma versão futura.

Eu acrescentaria que a desvantagem de excluir ramificações é que você quebrará quaisquer hiperlinks para essas ramificações no GitHub (essa pergunta está marcada como github). Você receberá um 404 Not Founderro para esses links. É por isso que altero meus links para apontar para uma confirmação ou marca após excluir uma ramificação no GitHub.

Como alguns links não podem ser alterados, como no email, agora evito hiperlinks para as ramificações do GitHub inteiramente e vinculo a um commit ou tag desde o primeiro dia.

Prefiro excluir ramificações depois que elas são mescladas. Isso evita a confusão visual de uma longa lista de ramificações em seu repositório. Essas ramificações também são propagadas para todos os garfos do repositório.

Primeiro, excluo minha filial local. Isso evita que ele seja empurrado acidentalmente mais tarde.

git branch -d branchName

Em seguida, excluo o ramo de rastreamento remoto

git branch -dr remoteName\branchName

Então eu apago a ramificação no GitHub. Eu uso a interface da web, mas o comando equivalente está abaixo.

git push remoteName :branchName

Mesmo que o ramo nunca seja mesclado, normalmente eu ainda gostaria de manter os commits disponíveis para a posteridade. No entanto, ainda gosto de excluir o ramo. Para espalhar as confirmações e impedir que elas sejam comidas pelo coletor de lixo, eu faço uma marca anotada apontando para a mesma confirmação que a ramificação excluída.

git tag -a tagName commitOrBranchName

Então eu empurro a tag para o github

git push remoteName tagName

Parece que você deseja excluir o 2011_Hotfixramo sem perder o histórico. Discutirei a exclusão primeiro e a história depois.

Os gitmétodos usuais de exclusão de ramificação já foram descritos acima e funcionam conforme o esperado. gitnão possui um comando de uma ou duas palavras que significa "Ei git, exclua as ramificações local e remota". Mas esse comportamento pode ser imitado via shell script. Por exemplo, considere o script de shell de Zach Holman 'git-nuke' . É muito simples:

#!/bin/sh
git branch -D $1
git push origin :$1

Coloque isso em um arquivo executável (por exemplo, git-nuke) em um de seus $PATHdiretórios. Se você não estiver no 2011_Hotfixramo, você simplesmente executando git-nuke 2011_Hotfixexcluirá os ramos local e remoto. Isso é muito mais rápido e simples - embora talvez mais perigoso - do que o padrãogit comandos .

Sua preocupação com a preservação da história é boa. Nesse caso, você não precisa se preocupar. Uma vez que você mesclar 2011_Hotfixpara master, todas as submissões de 2011_Hotfixserá adicionado ao master's cometer história. Em resumo, você não perderá o histórico de uma mesclagem simples.

Tenho mais uma palavra a acrescentar que talvez esteja além do escopo da sua pergunta, mas seja relevante no entanto. Vamos imaginar que há 20 minúsculos "trabalhos em andamento" confirmados 2011_Hotfix; no entanto, você deseja que apenas uma confirmação completa 2011_Hotfixseja adicionada ao masterhistórico da. Como você combina todas as 20 pequenas confirmações em uma grande confirmação? Felizmente, gitpermite consolidar várias confirmações em uma confirmação usando git-rebase. Não vou explicar aqui como isso funciona; no entanto, se você estiver interessado, a documentação paragit-rebase é excelente. Observe que git rebasereescreve o histórico, portanto ele deve ser usado criteriosamente, especialmente se você é novo nele. Finalmente, seu 2011_Hotfixcenário é sobre um time de desenvolvimento, não um desenvolvedor solo. Se os membros da equipe do projeto usaremgit rebase, é aconselhável que a equipe tenha diretrizes explícitas sobre o uso git rebase, para que algum desenvolvedor de cowboys da equipe não danifique involuntariamente o githistórico de um projeto .

Se ele tiver sido mesclado com êxito e talvez até marcado, eu diria que não tem mais uso. Então você pode fazer com segurança git branch -d branchname.

Se você deseja remover ramificações locais que foram removidas da origem, também é possível remover, enquanto estiver usando git fetch

git fetch --prune

Você pode excluir ramificações em todas as principais UIs da web, como github, BitBucket. Após excluir a filial online, você pode excluir a filial local usando

git remote prune origin