Quais são os prós e os contras do git-flow vs github-flow? [fechadas]

Recentemente, começamos a usar o GitLab.

Atualmente usando um fluxo de trabalho "centralizado".

Estamos pensando em mudar para o github-flow, mas quero ter certeza.

Quais são os prós e os contras do git-flow vs github-flow ?

Conforme discutido no episódio 17 do GitMinutes, por Nicholas Zakas em seu artigo " Fluxos de trabalho do GitHub dentro de uma empresa ":

O Git-flow é um processo para gerenciar alterações no Git, criado por Vincent Driessen e acompanhado por algumas extensões do Git para gerenciar esse fluxo.
A ideia geral por trás git-fluxo é ter vários ramos distintos que sempre existem, cada um para uma finalidade diferente: master, develop, feature, release, e hotfix.
O processo de desenvolvimento de recurso ou bug flui de um ramo para outro antes de finalmente ser lançado.

Alguns dos entrevistados indicaram que usam git-flowem geral.
Alguns começaram git-flowe se afastaram dele.

O principal motivo para se afastar é que o git-flowprocesso é difícil de lidar em um modelo de implantação contínua (ou quase contínua).
A sensação geral é de que git-flowfunciona bem para produtos em um modelo de lançamento mais tradicional, em que os lançamentos são feitos uma vez a cada poucas semanas, mas esse processo se deteriora consideravelmente quando você está lançando uma vez por dia ou mais .

Em resumo:

Comece com um modelo o mais simples possível (como o fluxo do GitHub tende a ser) e avance para um modelo mais complexo, se necessário.

Você pode ver uma ilustração interessante de um fluxo de trabalho simples , baseado no GitHub-Flow em:
" Um modelo simples de ramificação do git ", com os principais elementos:

1. master sempre deve ser implantável.
2. todas as alterações feitas através de ramificações de recursos (solicitação de pull + mesclagem)
3. rebase para evitar / resolver conflitos; fundir-se amaster

Para um fluxo de trabalho real mais completo e robusto, consulte gitworkflow (uma palavra) .

Não há fluxo de trabalho com bala de prata onde todos devem seguir, pois todos os modelos são abaixo do ideal. Dito isto, você pode selecionar o modelo adequado para o seu software com base nos pontos abaixo;

Várias versões em produção - use o Git-flow

Se o seu código tiver várias versões em produção (por exemplo, produtos de software típicos como sistemas operacionais, pacotes do Office, aplicativos personalizados etc.), você poderá usar o git-flow. O principal motivo é que você precisa oferecer suporte contínuo a versões anteriores em produção enquanto desenvolve a próxima versão.

Versão única no software simples de produção - use o Github-flow

Se o seu código tiver apenas uma versão em produção o tempo todo (por exemplo, sites, serviços da web etc.), você poderá usar o github-flow. O principal motivo é que você não precisa fazer coisas complexas para o desenvolvedor. Depois que o desenvolvedor termina um recurso ou corrige um bug, ele é imediatamente promovido para a versão de produção.

Versão única em produção, mas software muito complexo - use o Gitlab-flow

Software grande como o Facebook e o Gmail, pode ser necessário introduzir ramificações de implantação entre sua filial e a filial principal, onde as ferramentas de CI / CD> poderiam ser executadas antes de entrar em produção. A idéia é introduzir mais proteção na versão de produção, já que é usada por milhões de pessoas.

Estou usando o modelo git-flow há mais de um ano e está tudo bem.

Mas isso realmente depende de como o aplicativo será desenvolvido e implantado.

Funciona bem quando você tem um aplicativo que possui um fluxo lento de desenvolvimento / implantação.

Mas, por exemplo, como o GitHub, temos um aplicativo que tem um fluxo rápido de desenvolvimento / implantação, implantamos todos os dias e, às vezes, várias vezes ao dia, nesse caso, o git-flow tende a desacelerar tudo na minha opinião, e eu uso o GitHub fluxo.

A outra coisa a considerar é que o fluxo git não é um git padrão, então você pode, e quando eu digo que sim, quero dizer, você encontrará desenvolvedores que não o conhecem e, em seguida, há a curva de aprendizado, mais chance de estragar as coisas. Também como mencionado acima, alguém desenvolveu um conjunto de scripts para facilitar o uso do git-flow, para que você não precise se lembrar de todos os comandos, ele o ajudará com os comandos, mas lembrar que o fluxo real é seu trabalho , Me deparei com mais de uma vez quando um desenvolvedor não sabia se era um hotfix ou recurso ou, pior ainda, quando não conseguia se lembrar do fluxo e das coisas.

Há pelo menos uma GUI que suporta git-flow para Mac e Windows SourceTree .

Atualmente, estou mais inclinado ao fluxo do GitHub, devido à sua simplicidade e facilidade de gerenciamento. Além disso, por causa de "implantar cedo implante frequentemente" ...

Espero que isto ajude