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


124

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 ?

Respostas:


133

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

https://a248.e.akamai.net/camo.github.com/9783623eba280ba5ace8b9e63842be52af2f0546/687474703a2f2f7374617469632e62656e65742e61692f736b697463682e6262e3e3e3d3d3d3d3d3d3d3d


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


88

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.


7
Apenas adicionando "Gitdmz-flow" / "Git DMZ Flow" à lista: gist.github.com/djspiewak/9f2f91085607a4859a66
Robert Fey

1
As empresas referenciadas usam um sistema baseado em tronco. paulhammant.com/2014/01/08/…
PatrickWalker 14/10

1
O fluxo DMZ do Git é mais semelhante ao Gitflow e o ramo DMZ é como o ramo de desenvolvimento. Portanto, não sinto nada de especial nisso.
Gayan Pathirage

2
Pelo meu entendimento, o Git-Flow não funciona bem com a versão de produção múltipla. A estratégia de hotfix pressupõe que você tenha apenas uma versão de produção e o hotfix no ramo de lançamento correspondente (e depois o mescla novamente para desenvolver o ramo). Parece não atender como você pode corrigir um bug existente em vários ramos de produção.
Adrian Shum

5
@GayanPathirage Na verdade, não é. 1. Tags "clássicas" do GitFlow no mestre. A ramificação de hotfix serve apenas para você corrigir a versão de produção mais recente (do mestre). 2. "release branch" significa outra coisa no Gitflow, que na verdade é o branch de pré-lançamento (ramificação do branch de desenvolvimento, com o objetivo de mesclar para dominar quando é realmente lançado). 3. O que você está se referindo é algo chamado "ramo de suporte" no GitFlow (Essa é uma das razões pelas quais eu não gosto do GitFlow: terminologia não convencional). No entanto, ainda é o fluxo experimental (para que você não vê-lo na maior parte do Gitflow Lança)
Adrian Shum

38

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


+1. Eu concordo com você.
VonC 26/09

2
O fluxo do GitHub está dentro do Git-Flow. Pense que se você precisar de integração e implantação contínuas, basta executar o máximo possível com o branch de desenvolvimento. Cada recurso é ramificado do ramo de desenvolvimento. Talvez você não precise da ramificação principal ou da liberação, a menos que tenha modelos de implantação complexos. (por exemplo, sua versão 1.1 está ativa em algum cliente, sua 1.2 está ativa em outro cliente e atualmente você desenvolve a versão 1.3 para o seu novo cliente). Todos os três clientes solicitarão correções de erros e alterações em suas respectivas versões.
Gayan Pathirage

Olá Diego e obrigado pela sua resposta. E a manutenção de várias versões? Você faz isso facilmente com o Git Flow? Ouvi dizer que é difícil, pois você precisa de ramos de suporte! Você acredita que o modelo é adequado para isso?
Luis Gouveia

1
Olá Luis, acho que você pode fazer o modelo funcionar, mas novamente sinto que você pode conseguir o mesmo com um fluxo de trabalho padrão do git.
Diego Antunes

1
@LuisGouveia, na verdade, desde a sua pergunta e minha resposta acima, me deparei com um projeto em que o git-flow funcionará perfeitamente, e eu sou o proprietário do projeto. A idéia é usar git flow release...em combinação com ações do github para implantar o aplicativo. Na minha resposta original, mencionei que lançamos várias vezes em um dia, isso causou problemas ao usar o git-flow. A razão pela qual acho que o git-flow funcionará bem neste projeto é porque temos um ciclo de lançamento predefinido, que é um dos principais pontos de venda para usar o git-flow.
Diego Antunes
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.