Quando é o momento certo para deletar um branch de recurso git?

90

Eu não quero acabar com 82 branches de recursos por aí , então estou me perguntando quais são as possíveis desvantagens de simplesmente excluir o branch de recursos assim que mesclá-lo com o master.

Fluxo de trabalho:

git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

Algum problema aqui?

git version-control branch

— bstpierre
fonte

1

Eu diria que não há problemas porque se você realmente precisar deles, você sempre pode ressuscitar o branch excluído mais tarde.

— slebetman

@slebetman Pelo que eu sei, um branch excluído não pode ser ressuscitado. No entanto, se o branch foi totalmente mesclado no master antes de excluí-lo, não deverá haver mais necessidade do branch.

— Simeon,

1

@Simeon Sim, você pode. Git nunca deleta commits, então quando você deleta seu branch você está deletando seu nome. Para ressuscitar um branch excluído, você só precisa se lembrar da última coisa que comprometeu com aquele branch e pode pesquisá git reflog-lo. Em seguida,

— verifique

@slebetman isso só será verdadeiro se o branch for finalmente mesclado. se os commits forem deixados para trás, eles eventualmente se tornarão inacessíveis e estarão sujeitos à coleta de lixo após um certo período de tempo. mesmo as entradas no reflog serão eventualmente eliminadas, você tem cerca de 90 dias por padrão.

— goldenratio

@goldenratio: Alguma referência para isso?

— slebetman

63

Excluir após mesclar é a maneira usual. É por isso que git branch -d yourbranchnameverifica se o branch está totalmente mesclado antes de ser excluído.

Existem alguns motivos que posso pensar para manter um branch por perto: você pode querer mantê-lo no caso de haver bugs voltando assim que chegar à produção, ou você pode querer um registro histórico.

Em ambos os casos, você tem a opção de marcar o chefe do ramo antes de excluí-lo. Uma tag é como um branch no sentido de que é um ponteiro para um commit, exceto por algumas pequenas diferenças: 1) porcelain geralmente não exibe tags em comandos exploratórios como git show-branch ou tab-auto complete no checkout, 2) fazer check-out coloca você em um (não ref) HEAD 3) destacado, você pode deixar uma " mensagem de tagging ", que faz com que a tag seja salva como um objeto no armazenamento de objeto como um commit.

Dessa forma, você preserva o histórico e, se precisar corrigir o bug, recomendo apenas criar um novo branch do master para a correção.

— masonk
fonte

1

Verificar uma tag define HEAD, mas não cria automaticamente um branch. Um HEAD em um commit sem um branch é o que o torna desanexado.

— Binarian

1

Você está certo, ele define HEAD para um ID de commit ao invés de um ref. Essa parte do meu OP está incorreta. Eu deveria atualizá-lo.

— Masonk

97

Eu excluo após mesclar, mas sempre faço uma git merge --no-ff, para evitar o avanço rápido de forma que o histórico de ramificações fique visível no gráfico. Gosto de ter o histórico de onde o branch de recurso partiu do branch de desenvolvimento e de onde voltou:

Mesclando com ou sem avanço rápido

Isso foi tirado de Um modelo de ramificação Git bem-sucedido de Vincent Driessen, um fluxo de trabalho muito bom para usar com o git que aplico na maioria dos meus projetos.

— lkraider
fonte

Esta é outra boa maneira de preservar o histórico, porque você pode selecionar os commits que são acessíveis a partir do recurso, mas não do master: rev ^ 1..rev ^ 2. O lado ruim é que isso atrapalha qualquer rebase que você queira fazer a partir de seu branch master (por exemplo, se você quiser manter o rebase master no upstream remote, o que é muito comum).

— Masonk

1

Eu não tive esse problema. Nossa equipe sincroniza através do github, e eu geralmente não preciso rebase, mas não acho que seja uma desvantagem aqui. Mesmo se você rebase seu branch de desenvolvimento e recurso, a ramificação permanece visível no gráfico, e o que importa é o que está no branch de recurso relativo ao desenvolvimento, não o commit de onde você partiu originalmente quando criou aquele branch.

— lkraider

@Ikraider, obrigado pelo lembrete. Eu vi aquele artigo quando estava aprendendo git pela primeira vez, faz mais sentido para mim agora. Eu rebasei meus branches de recursos, mas merge --no-ffvolto ao master porque, como você disse, você pode ver o histórico.

— bstpierre

7

Posso pensar em dois motivos pelos quais você pode querer manter um branch de recursos por um tempo:

Há uma chance de que ele seja enviado de volta para você para mais trabalho pelo upstream.
Outros desenvolvedores possivelmente desejam esse recurso sem querer todo o resto no master.

Na prática, na maioria das vezes, a exclusão após a mesclagem é adequada.

— Karl Bielefeldt
fonte

6

Fluxo de trabalho típico será

 // Create new branch
 $ git checkout -b myfeature
 // and then do some changes and commit them

 // Switch to master branch
 $ git checkout master

 // Merge myfeature to master. --no-ff will always keep branch information.
 $ git merge --no-ff myfeature

 // Delete myfeature branch
 $ git branch -d myfeature

 // Push the changes
 $ git push origin master

— Fizer Khan
fonte

1

Eu acho que é o fluxo de trabalho típico (exclusão após mesclagem)

EDIT Então, ao invés de mesclar, pelo menos para branches de curta duração, eu acho que a ideia é realocá-los no master. então, você acaba com um histórico de alterações lineares e toda a ramificação se torna parte do tronco principal. neste caso, você tem todas as alterações lá, portanto, claramente não precisa de uma cópia.

— segundo
fonte

Portanto, não há realmente nenhum ponto em manter o galho por perto, certo?

— bstpierre

1

Eu recomendo fortemente evitar "rebase". Rebasing é geralmente prejudicial, útil apenas em alguns casos.

— Dietrich Epp de

9

Rebasing é um fluxo de trabalho perfeitamente razoável para suas filiais privadas locais. É muito comum manter a sincronia com o trabalho upstream, rebasing, por exemplo ("rebasing down "). É muito menos comum e geralmente prejudicial fazer rebase *. A resposta da segunda realmente não faz sentido, porque se você estiver fazendo um rebase ou mesclando as alterações do upstream, ainda terá que empurrar essas coisas para cima de alguma forma. Mesmo em seu branch local, você terá que mesclar seu recurso para dominar em algum ponto. A vantagem de permanecer baseado em seus recursos é que essa mesclagem se torna um avanço rápido.

— Masonk

1

No entanto, há algo a ser observado com a rebase de galhos, que me incomodou recentemente. É óbvio agora, mas passei meses em um galho de longa duração, sempre rebatizando a coisa toda contra o mestre. Acabou ficando em torno de 600 commits granulares, mas o master foi totalmente refatorado e totalmente alterado várias vezes. Ao rebasear todo o branch toda vez, eu estava cortando seus commits mais antigos de sua conexão para os commits principais que faziam sentido para eles. Agora eu prefiro mesclar no master quando necessário. Só rebasearei se o histórico do branch não for absolutamente afetado.

— Gary Fixler,