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?

Página de manual do gitworkflows (7)(nvie) Um modelo de ramificação Git bem-sucedido(reinh) Um fluxo de trabalho do Git para equipes ágeis

Mesclando vs rebasing (emaranhado x histórico seqüencial)

Deveriapull --rebase ou aguarde mesclando 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 até prefiromerge --no-ff para esse fim. No entanto, há outras desvantagens. Muitos também não perceberam a propriedade útil da fusão - que não écomutativo (mesclar uma ramificação de tópico no mestre não significa mesclar mestre na ramificação 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, basear-se suficientemente a jusante para que seja possível mesclar a montante em todas as ramificações necessárias (o uso desses termos é suficientemente claro?). 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 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 terminar 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? Aplicar o 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?

Procedimentos adequados, como revisão de código e graduação claro que seria adorável.

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 internoFluxo de trabalho Git para desenvolvimento corporativo de kernel LinuxComo você mantém o código de desenvolvimento e o código de produção? (obrigado poresta PDF!)gerenciamento de lançamentos gitGit Cherry-pick vs Merge WorkflowComo escolher várias confirmações de cerejaComo você mescla arquivos seletivos com o git-merge?Como escolher uma variedade de confirmações e mesclar em outra ramificaçãoReinH Git Workflowfluxo de trabalho git para fazer modificações que você nunca voltará à origemEscolha uma mesclagem de cerejaFluxo de trabalho Git adequado para sistema operacional combinado e código privado?Mantendo o projeto com o GitPor 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 GitQuando o "git pull --rebase" me leva a problemas?Como o DVCS é usado em equipes grandes?

Verifique também o que o Plastic SCM escreve sobredesenvolvimento orientado a tarefase, se o plástico não for sua escolha, estudemodelo de ramificação de nvie e elescripts de suporte.