Existem falhas neste modelo de ramificação do Git?

Estou perguntando sobre esse modelo ou fluxo de trabalho de ramificação do git . Eu realmente gosto disso. Parece-me muito intuitivo e produtivo, mas o que estou pedindo é se existem falhas ou negativos nessa abordagem que ainda não estão claros para mim (vindos de outro mundo em que o ClearCase governou o dia).

(Você não precisa responder todas as perguntas, o que puder é útil)

1. Você usa esse ou um fluxo de trabalho de ramificação git semelhante?

2. Você considera isso uma abordagem produtiva?

3. Você vê alguma falha nessa abordagem? Alguma desvantagem em potencial?

4. Se você tem uma abordagem melhor, você se importaria em compartilhar ou fornecer um link para um artigo ou discussão sobre isso?

Na maioria das vezes, esse é o fluxo de trabalho usual empregado em qualquer VCS que usamos até agora. Com alguns (CVS, SVN), é mais difícil de fazer, com o GIT é trivial. Dito isto, tenho duas observações:

Primeiro, existem duas escolas de pensamento quando se trata de ramos principais:

1. Mesclá-los
2. Rebase eles

(1) é o que o artigo parece sugerir. O problema com as confirmações de mesclagem são as chamadas mesclagens malignas . Especificamente, aqueles que ingressam nos caminhos de desenvolvimento em que uma função alterou a semântica em uma das ramificações, mas a mesclagem automática falha ao corrigir todas as ocorrências no código provenientes da outra ramificação. Regressões introduzidas dessa maneira são notoriamente difíceis de depurar. Como usuário do GIT, geralmente você pode ficar muito mais tranquilo com as regressões, porque precisa git bisectencontrar as causas para você automaticamente. No entanto, na situação descrita, git bisectapontará o commit de mesclagem, o que não ajuda em nada.

(2) evita esse problema tentando manter uma história o mais linear possível. Os rebotes opostos alegam que isso invalida qualquer teste que você possa ter feito antes do rebase.

Pessoalmente, estou firmemente no campo (2), porque valorizo ​​a validade dos git bisectresultados mais do que a perda potencial de cobertura de teste, que é facilmente compensada pelo uso de um sistema de IC adequado.

Segundo, decidi para mim que empurrar entre desenvolvedores raramente é uma boa idéia. Existem problemas de segurança envolvidos para permitir que todos busquem na sua caixa ou executar o git-deamon localmente e, mais importante, em equipes não muito pequenas, a supervisão pode se perder rapidamente.

Dito isso, sou a favor de um repositório de teste (às vezes também chamado de scratch ), que permite que as subequipes compartilhem seu trabalho em andamento por meio de um servidor central que é, no entanto, diferente do principal (geralmente externo) de frente, se não for público). Normalmente, cada subequipe manteria uma ramificação de tópico para si mesma, e um sistema de IC executaria mesclagens periódicas de polvo de todas as ramificações de tópico em uma grande ramificação de integração, reclamando de conflitos e criando erros.

Atualmente, estou no processo de fazer refatorações maciças e de longa data (converter um aplicativo de um para outro kit de ferramentas da GUI) e executar um fluxo de trabalho bem-sucedido e centrado em rebase, porque outros membros da equipe continuam trabalhando em novos recursos:

Existem principalmente dois ramos principais, masteronde os novos recursos são desenvolvidos e o toolkit-conversionramo. A regra mais importante é simples: faça apenas coisas no toolkit-conversionramo que sejam relevantes para a conversão. Sempre que há algo que pode ser feito no master(antigo kit de ferramentas da GUI), eu faço lá e refiz minhas toolkit-conversionalterações para o novo mastercabeçalho. Outra regra é manter o toolkit-conversionramo bastante curto. Por isso, costumo usar reset, pick-cherry e commit-commit e rebase para colar pertences menores a outros maiores (que no final têm o mesmo objetivo). Isso também funciona bem quando tentei algo que não funcionou bem para "desfazer" a alteração ou depois de refatorar algum código com código auxiliar temporário.

Eu decidi contra mesclar as alterações de masterem toolkit-conversionramo, porque iria torná-lo muito mais difícil de rebase commits anteriores para manter o ramo limpo e fácil de revisão. Além disso, as mesclagens podem introduzir conflitos cujas resoluções não são tão claras como quando se mantém um histórico limpo.

Obviamente, esse fluxo de trabalho também tem desvantagens. O mais importante é que ele só funciona bem para uma única pessoa. Sempre que eu forço a toolkit-conversionramificação forçada depois de a ter rebaseado para a cabeça master, é difícil puxá-la para outro repositório (rebasear automaticamente na ramificação de rastreamento geralmente falha com conflitos).

No final, minha toolkit-conversionfilial permanece curta, limpa e fácil de revisar. Eu não poderia imaginar ter feito isso de maneira semelhante com o SVN, por exemplo.

Na empresa em que estou trabalhando, aplicamos uma variação desse mesmo modelo de ramificação há um tempo. Também usamos scrum, por isso fazemos uma ramificação por fluxo de trabalho de história.

O único problema que tivemos até agora é quando a equipe é grande o suficiente e mais de uma história pode ser iniciada e essas histórias dependem uma da outra.

Além disso, isso provou ser confiável :).

No momento, estou ocupado adaptando esse fluxo de trabalho. Eu acho que esse é um bom fluxo de trabalho, porque ele usa o modelo de ramificação em que o git se destaca.

A única pequena desvantagem é que é preciso disciplina para manter esse fluxo de trabalho e não tentar usar atalhos.

Os desenvolvedores do kohana também usam esse fluxo de trabalho, e eles parecem gostar bastante.

Você usa esse ou um fluxo de trabalho de ramificação git semelhante?

Usamos um fluxo de trabalho semelhante no trabalho, mas um pouco menos complicado. No entanto, ele é bastante inspirado por esse fluxo de trabalho, já que li este artigo várias vezes. Até tenho o pdf do modelo de ramificação impresso em cores ao lado da minha mesa :)

Você considera isso uma abordagem produtiva?

Produtivo. Como você define produtividade? Bem, na minha opinião, é mais importante ter alta qualidade, pelo menos tentar obter melhor qualidade o tempo todo. Melhorando constantemente o processo etc. Se você pode produzir um código de qualidade, a produtividade se beneficiará dele. Portanto, a questão é realmente: isso melhora a qualidade do software? E minha resposta para isso é definitivamente sim.

O que eu mais amo com esse tipo de modelo de ramificação é que ele introduz ramificações em diferentes camadas de qualidade. Quanto mais à direita na imagem, maior estabilidade e maior qualidade. O ramo principal é sagrado e todas as confirmações nele devem ser consideradas versões estáveis ​​do software. Quanto mais à esquerda você for, mais experimental e menor será a estabilidade.

Assim que você testar novos recursos e correções, poderá transferi-los gradualmente da esquerda para a direita e, assim, mover o código com alta qualidade exatamente quando você souber que o código atende aos requisitos de qualidade exigidos pelo código. Bem, pelo menos em teoria, já que você não pode testar tudo a 100% e sabe com certeza que o código não contém nenhum erro, porque ele sempre terá erros. Mas permite manter uma alta confiança.

Nada é mais péssimo como programador do que trabalhar em um sistema em que ninguém confia no código, porque eles sabem que isso é péssimo e que há uma merda de bugs nele.

Você vê alguma falha nessa abordagem? Alguma desvantagem em potencial?

É importante pensar em seu modelo de ramificação para que ele se adapte bem às necessidades da sua organização. Só porque esse modelo funciona bem para algumas pessoas, não significa necessariamente que seja ideal ou desejável para outra.

Sempre existem trade-offs e até nesse caso. Uma troca é o número de ramificações versus complexidade. Ao introduzir muitos tipos diferentes de ramificações, você aumenta a complexidade do fluxo de trabalho. Por exemplo, pode ser errado sempre forçar as pessoas a criar um novo ramo de recursos, quando estão tentando corrigir um bug simples, alterando algumas linhas de código.

Todos sabemos que os bugs são mais ou menos complicados de resolver. Portanto, quando um bug trivial é descoberto, você pode reduzir a complexidade e a administração para se livrar da sobrecarga extra e deixar as pessoas se comprometerem diretamente com, por exemplo, o mestre ou o ramo de desenvolvimento. Mas, como a natureza de suas correções se torna mais complicada, vale a pena extra para criar novas ramificações para elas. Especialmente se você não tiver certeza do tamanho e comprimento ou se deseja melhorar a colaboração entre você e os outros desenvolvedores.

Se você tem uma abordagem melhor, você se importaria em compartilhar ou fornecer um link para um artigo ou discussão sobre isso?

Essa é, sem dúvida, uma boa abordagem e pode ser adequada à maioria dos casos, já que a maioria de nós possui processos de desenvolvimento semelhantes, mas pode não ser adequada para todos. Peço fortemente que você pense como você lida com seu código agora e tente criar um modelo de ramificação que se encaixe no que você já possui.

O ponto mais importante é começar com o git e o resto seguirá naturalmente. Comece simples e melhore gradualmente! Seja criativo!

Felicidades