Atualmente, nossa empresa está usando um modelo de ramificação simples de tronco / release / hotfixes e gostaria de receber conselhos sobre quais modelos de ramificação funcionam melhor para sua empresa ou processo de desenvolvimento.
Fluxos de trabalho / modelos de ramificação
Abaixo estão as três principais descrições que eu já vi, mas elas se contradizem parcialmente ou não vão longe o suficiente para resolver os problemas subseqüentes nos quais encontramos (conforme descrito abaixo). Portanto, nossa equipe, até o momento, adota soluções não tão boas. Você está fazendo algo melhor?
Mesclando vs rebasing (emaranhado x histórico seqüencial)
Deve-se
pull --rebaseesperar com a mesclagem de volta à linha principal até que sua tarefa seja concluída? Pessoalmente, eu me inclino para a mesclagem, pois isso preserva uma ilustração visual de em que base uma tarefa foi iniciada e finalizada, e eu até prefiromerge --no-ffpara esse fim. No entanto, há outras desvantagens. Muitos também não perceberam a propriedade útil da mesclagem - que não é comutativa (mesclar um ramo de tópico no mestre não significa mesclar o mestre no ramo de tópico).Estou procurando um fluxo de trabalho natural
Às vezes, erros acontecem porque nossos procedimentos não capturam uma situação específica com regras simples. Por exemplo, uma correção necessária para liberações anteriores deve, obviamente, ser baseada suficientemente a jusante para que seja possível mesclar a montante em todas as ramificações necessárias (o uso desses termos é claro o suficiente?). No entanto, acontece que uma correção entra no mestre antes que o desenvolvedor perceba que deveria ter sido colocado mais a jusante, e se isso já foi enviado (ainda pior, mesclado ou algo com base nele), a opção restante é escolher a cereja, com seus perigos associados. Que regras simples como essas você usa?Também está incluído o constrangimento de uma ramificação de tópico, excluindo necessariamente outras ramificações de tópico (supondo que elas sejam ramificadas a partir de uma linha de base comum). Os desenvolvedores não querem concluir um recurso para iniciar outro, sentindo que o código que acabaram de escrever não existe mais
Como evitar a criação de conflitos de mesclagem (devido à seleção de cereja)?
O que parece uma maneira certa de criar um conflito de mesclagem é escolher entre ramificações, elas nunca poderão ser mescladas novamente? A aplicação do mesmo commit na reversão (como fazer isso?) Em qualquer ramo possivelmente resolveria essa situação? Esse é um dos motivos pelos quais não me atrevo a pressionar por um fluxo de trabalho amplamente baseado em mesclagem.
Como se decompor em ramos tópicos?
Percebemos que seria incrível montar uma integração finalizada das ramificações de tópicos, mas muitas vezes o trabalho de nossos desenvolvedores não está claramente definido (às vezes, tão simples quanto "bisbilhotar") e se algum código já tiver entrado em um tópico "misc", não pode ser retirado de lá novamente, de acordo com a pergunta acima? Como você trabalha para definir / aprovar / formar / liberar suas ramificações de tópicos?
É claro que procedimentos adequados, como revisão de código e graduação, seriam adoráveis.
Mas simplesmente não podemos manter as coisas emaranhadas o suficiente para gerenciar isso - alguma sugestão? ramos de integração, ilustrações?
Abaixo está uma lista de perguntas relacionadas:
- Quais são algumas boas estratégias para permitir que os aplicativos implantados sejam corrigidos?
- Descrição do fluxo de trabalho para uso do Git para desenvolvimento interno
- Fluxo de trabalho Git para desenvolvimento corporativo de kernel Linux
- Como você mantém o código de desenvolvimento e o código de produção? (obrigado por este PDF!)
- gerenciamento de lançamentos git
- Git Cherry-pick vs Merge Workflow
- Como escolher várias confirmações de cereja
- Como você mescla arquivos seletivos com o git-merge?
- Como escolher uma variedade de confirmações e mesclar em outra ramificação
- ReinH Git Workflow
- fluxo de trabalho git para fazer modificações que você nunca voltará à origem
- Escolha uma mesclagem de cereja
- Fluxo de trabalho Git adequado para SO e código privado combinados?
- Mantendo o projeto com o Git
- Por que o arquivo de mesclagem Git não pode ser alterado com um pai / mestre modificado.
- Boas práticas de ramificação / reestruturação do Git
- Quando o "git pull --rebase" me leva a problemas?
- Como o DVCS é usado em equipes grandes?
Verifique também o que o Plastic SCM escreve sobre o desenvolvimento orientado a tarefas e, se o Plastic não for sua escolha, estude o modelo de ramificação do nvie e seus scripts de suporte .