Esquecer de mesclar alterações de tronco para filial

Question

Esquecer de mesclar alterações de tronco para filial

#1 resposta do (4 votos)
#2 resposta do (1 votos)
#3 resposta do (1 votos)

5

Recentemente, esqueci de mesclar as alterações do tronco para o ramo de manutenção. Isso nos fez reconstruir - duas vezes - e colocar o controle de qualidade em espera por dois dias enquanto consertávamos a bagunça.

Normalmente, ao se comprometer com as duas ramificações, eu envio um único conjunto de alterações para o tronco e mescle-o imediatamente na ramificação de manutenção.
No entanto, desta vez houve 12 changesets abrangendo muitas alterações de revisão de código e não consegui mesclar todas as alterações. Eu tinha apenas fundido uma mudança, o que me jogou completamente fora - eu pensei que eu lembrava que era um commit de todos os outros changesets, mas não era.

Depois de algumas discussões de desenvolvimento, decidimos que a melhor abordagem seria fazer com que o tronco 1-para-1 e o ramo de manutenção fossem confirmados, para que você pudesse verificar visualmente se todo o código estava lá.

Existe uma maneira de impor commits de changeset para uma determinada versão de correção?
Nós usamos JIRA , Fisheye e Crucible e nosso fluxo de trabalho Fisheye não permite que você resolva um problema, a menos que o código revise estão completos. Gostaria de algo semelhante que impunha check-ins paralelos nas ramificações de tronco e manutenção, com base na versão de correção especificada no problema.

Ou há uma solução melhor para essa bagunça toda além de "não fazer isso"?

version-control branching issue-tracking builds failure

por mskfisher 02.06.2011 / 17:14

fonte

3 respostas

Tags version-control branching issue-tracking builds failure

Aceder aleatoriamente a pacotes de dados num ficheiro comprimido Rails: controllers vs models que devem manipular a manipulação de arquivos

score 4 · Answer 1

Obviamente isso só funciona se você usa o git, mas aqui está como eu me aproximo ...

Cada solicitação de recurso e cada bug recebem sua própria filial localmente. O desenvolvedor então faz todas as alterações necessárias. Quando eles terminarem, rebase o branch e mescle / divida os commits em unidades de trabalho lógicas. Para pequenos recursos e para correções de bugs, isso não deve ser difícil mantê-los em um único commit. Para recursos maiores, você pode querer ter vários commits, por exemplo: "Add interface for foo". "Adicionar implementação de foo". "Faça o Whizbang usar o novo recurso foo". O objetivo é manter todas as linhas de código logicamente conectadas em um commit. Nesse ponto, a unidade de trabalho tem um (ou um conjunto) de confirmações. Seu bug tracker deve permitir que você vincule os commits aos tickets. O ticket do bugfix seria vinculado ao commit do bugfix e deveria ser fácil ver que o commit foi mesclado no branch apropriado.

score 1 · Answer 2

No meu trabalho, temos um software caseiro que nos ajuda a iniciar / terminar projetos. Quando você aterra o projeto, ele cria uma árvore, aplica suas alterações e, em seguida, mescla as alterações no tronco. (Você resolve conflitos lá.) Quando você termina, confirma (e apaga seu projeto).

Quando você inicia um projeto, especifica se é um hotfix ou não. Se for um hotfix, quando você o fizer, ele cria patches para o tronco e para o ramo de manutenção.

Claro que agora você precisa lembrar de tornar o projeto um hotfix. Mas fica mais fácil garantir que muitas mudanças relacionadas sejam cometidas juntas onde precisam estar.

score 1 · Answer 3

O que você fez é provavelmente o resultado de um defeito de processo que exige que você se lembre de fazê-lo (daí você o faz imediatamente), sem rastrear se ele realmente foi feito.

Pergunta: Você pode produzir facilmente um relatório que confirme que todas as mesclagens foram concluídas. Em caso afirmativo, a falha por um único indivíduo de uma única ação pode fazer com que o relatório fique incorreto (ou seja, você processa um modo de falha de ponto único)?

Você realmente tem 2 alterações necessárias. Uma é a entrega para o ramo principal e uma é a entrega no ramo de manutenção. Use o Jira para rastreá-los como duas entregas relacionadas.

Isso tem vantagens, como adiar uma mesclagem para a manutenção desejada e ainda ver o que foi adiado, mas tem uma sobrecarga. Ele também pode fazer com que seu sistema de relatórios gerencie mais defeitos que você realmente tem, dependendo de como você os registra e registra.