Git Flow - Uma forma legal de organizar repositórios git


Conheça o Git Flow, uma ferramenta desenvolvida para melhorar ainda mais o uso de repositórios GitUma dúvida muito comum a quem começa a usar o Git de maneira mais ativa é como organizar as branches, afinal, são muitos os problemas que um projeto pode enfrentar: De bugs urgentes que devem ser corrigidos, a criação de inúmeras features em conjunto com releases agrupando os deploys relativos a essas features. Mas..como organizar tudo? Pensando nisso é que foi criado o Git Flow, um modelo de organização de branches criado por Vincent Driessen que mais tarde se tornou uma excelente extensão ao Git, permitindo seu uso de forma fácil com qualquer repositório git, e é sobre isso que vou falar hoje.

Antes de começar a falar mais detalhadamente sobre o Git Flow, quero chamar atenção para o fato de que o Git Flow não é o único modelo de organização de branches: Existem outros por aí,  e inclusive existem empresas que adotam modelos de organização próprios, mas, disso tudo, um fato é que o Git Flow parece ser o mais conhecido e usado, se encaixando muito bem numa plenitude de situações, e sendo muito bom para trabalhos em equipe (por experiência própria). Se você conhecer alguma alternativa que funciona bem, mande nos comentários!

Agora, continuando as explicações sobre o Git Flow, como explicado no primeiro parágrafo, trata-se de um modelo de organização de branches desenvolvido especialmente para o git. Por ser primariamente um modelo de organização de branches, isso significa que o Git Flow estabelece algumas regras de nomenclaturas para tipos de branches enquanto, ao mesmo tempo, define o que cada tipo de branch faz. Para referência, segue uma lista dos tipos de branches definidos pelo Git Flow e suas respectivas descrições:

  • Branch master - É a branch que contém código em nível de produção, ou seja, o código mais maduro existente na sua aplicação. Todo o código novo produzido eventualmente é juntado com a branch master, em algum momento do desenvolvimento;
  • Branch develop - É a branch que contém código em nível preparatório para o próximo deploy. Ou seja, quando features são terminadas, elas são juntadas com a branch develop, testadas (em conjunto, no caso de mais de uma feature), e somente depois as atualizações da branch develop passam por mais um processo para então ser juntadas com a branch master;
  • Branches feature/* - São branches no qual são desenvolvidos recursos novos para o projeto em questão. Essas branches tem por convenção nome começando com feature/ (exemplo: feature/new-layout) e são criadas a partir da branch develop (pois um recurso pode depender diretamente de outro recurso em algumas situações), e, ao final, são juntadas com a branch develop;
  • Branches hotfix/* - São branches no qual são realizadas correções de bugs críticos encontrados em ambiente de produção, e que por isso são criadas a partir da branch master, e são juntadas diretamente com a branch master e com a branch develop (pois os próximos deploys também devem receber correções de bugs críticos, certo?). Por convenção, essas branches tem o nome começando com hotfix/ e terminando com o próximo sub-número de versão (exemplo: hotfix/2.31.1), normalmente seguindo as regras de algum padrão de versionamento, como o padrão do versionamento semântico, que abordei neste post;
  • Branches release/* - São branches com um nível de confiança maior do que a branch develop, e que se encontram em nível de preparação para ser juntada com a branch master e com a branch develop (para caso tenha ocorrido alguma correção de bug na branch release/* em questão). Note que, nessas branches, bugs encontrados durante os testes das features que vão para produção podem ser corrigidos mais tranquilamente, antes de irem efetivamente para produção. Por convenção, essas branches tem o nome começando com release/ e terminando com o número da próxima versão do software (seguindo o exemplo do hotfix, dado acima, seria algo como release/2.32.0), normalmente seguindo as regras do versionamento semântico, como falado acima;

Um aspecto interessante do Git Flow é que, quando você mistura uma branch release/ ou hotfix/ com a branch master, ele automaticamente cria git tags correspondentes aos merge commits da mistura, facilitando o trabalho de, por exemplo, mudar para uma versão mais antiga, e organizando todo o trabalho.

Mas...o que são git tags? Simples, se lembra do tutorial básico de git, no qual cada commit assume um hash único,  ao estilo bdbb064f6db74509148a8aae67177931413925a5? Então, git tags são como "atalhos" que possuem um nome mais amigável definido por você para um commit específico no repositório, e que podem ser acessadas facilmente usando git checkout . Em outro tutorial ensinarei melhor como usá-las, pois não vem ao ponto aqui (visto que as extensões do git flow as criam automaticamente).

Enfim, continuando, agora que você já sabe um pouco dos conceitos do Git Flow e como eles se aplicam (se você ficou com alguma dúvida, inclusive, poste sua dúvida nos comentários que eu farei questão de a responder!), vamos aplicar o que você aprendeu na prática? Partiu para o tutorial, então. 😉

Tutorial básico de git flow

Para esse tutorial básico de git flow, vou assumir que você está com o repositório criado no tutorial básico de git, que vai servir inclusive para mostrar que você, a qualquer momento, pode adaptar qualquer repositório git para começar a usar o Git Flow. Segue o passo-a-passo:

1) Primeiro, precisamos ter o Git Flow instalado na máquina. Como se trata de uma extensão ao Git, ele não vem instalado com o Git por padrão e para isso precisamos instalá-lo manualmente em sua máquina (mesmo se for a máquina do Vagrant usado no primeiro tutorial, pois eu me esqueci de instalar o Git Flow..). Segue o link para a documentação sobre como instalá-lo. E segue a gravação da instalação do Git Flow sendo feita na máquina virtual Vagrant fornecida no post do tutorial básico de git:

2) Agora, na pasta do repositório criado no tutorial básico de git, execute o comando "git flow init". Esse comando vai fazer algumas perguntas, como o prefixo desejado para as branches feature/, release/ e hotfix/*, e também o nome das branches master e develop, que são coisas que o Git Flow permite configurar mas que recomendo fortemente que deixe com os valores padrão. Ou seja, nesse caso, basta apertar Enter para todas as perguntas, deixando que o Git Flow seja inicializado com os valores padrão e recomendados. Veja:

Note que o Git Flow pergunta também o prefixo para branches support/. Bom, embora disponíveis, branches support/ ainda são muito experimentais e portanto não serão abordadas nesse tutorial.

Note que, durante a execução do comando, o Git Flow automagicamente criará a branch develop e fará git checkout automático para esta branch.

3) Agora, vamos criar uma nova feature branch? Para fazer isso, execute o comando "git flow feature start recurso-milionario" para criar uma nova feature branch chamada recurso-milionario, com o nome feature/recurso-milionario. Veja o comando em execução:

4) Nessa nova branch, crie um arquivo recurso.txt com o conteúdo "Este é o melhor recurso criado desde sempre!". Como feito no primeiro tutorial, execute os comandos "git add recurso.txt" e "git commit -m 'Finished feature'" para adicionar e commitar o arquivo em questão na feature branch recurso-milionario (se você tiver alguma dúvida relacionada a esses comandos, veja o tutorial básico de git). Veja:

5) Com o commit feito, podemos finalmente juntá-lo a branch develop. Para fazer isso, execute o comando "git flow feature finish recurso-milionario". Como visto abaixo:

Como você pode ver, a branch feature/recurso-milionario foi correspondentemente integrada à branch develop e o git flow fez checkout automático para a branch develop, te mostrando todos os passos feitos.

6) Agora que temos um recurso milionário na branch develop (risos), vamos criar uma release branch para poder enfim publicar a atualização na branch master? Para fazer isso, execute o comando "git flow release start 0.1.0". Veja:

7) Agora, com a release branch criada, vamos apenas fazer uma pequena alteração no arquivo recurso.txt, modificando a frase de "Este é o melhor recurso criado desde sempre!" para "Este talvez seja o melhor recurso criado desde sempre!", adicionando a mudança à area de estágio do git  usando "git add recurso.txt" e depois comittar a mudança na release branch usando "git commit -m 'Little bug-fix in feature'". Veja:

Note que só estamos fazendo este commit para lhe mostrar que sim, mudanças podem ser feitas antes da branch ser juntada com a branch master. Mas quero lhe lembrar que isso não é necessário, e que em muitos casos a release branch existe apenas por...existir, sendo imediatamente juntada com a branch master, sem mudanças adicionais.

8) Com a mudança registrada, vamos enfim juntar a release branch 0.1.0 com a branch master e a branch develop, para isso, vamos usar o comando "git flow release finish 0.1.0", que vai integrar a mudança feita à release branch 0.1.0 com as branches master e develop. Veja:

Como você pode ver acima, o Git Flow abre o editor de texto três vezes:

  • Uma para você editar o texto do merge commit relacionado ao merge entre a release branch 0.1.0 e a branch master;
  • Um para a descrição da tag 0.1.0, que será criada pelo Git Flow para facilitar mudanças de versão no software;
  • Uma para você editar o texto do merge commit relacionado ao merge entre a branch master e a branch develop;

Na primeira e na terceira vez, sugiro para que você deixe o texto padrão deixado pelo Git. Apenas na segunda vez, quando ele pede para você colocar uma descrição para a tag, é recomendado (e se não me engano, obrigatório) que você descreva exatamente o que foi adicionado e/ou modificado naquela versão (acredite, serve para referência futura).

9) Agora que a branch master foi atualizada com o novo recurso, suponhamos que foi encontrado um bug ultra-mega-hiper-critico na aplicação (coincidentemente, nesse exemplo, suponhamos que foi no mesmo recurso recém adicionado) e que ele é tão grave que está afetando o uso por todos os usuários da aplicação e por isso precisa ser corrigido com urgência máxima.

Para corrigir esse bug critico, vamos criar um hotfix usando o comando "git flow hotfix start 0.1.1", que criará uma hotfix branch chamada 0.1.1 que resolve um problema encontrado no release 0.1.0 (entendeu porque faz sentido usar versionamento semântico nos nomes de branches usando nas releases branches e hotfixs branches?). Veja:

10) Agora que temos a nossa hotfix branch 0.1.1 criada, vamos editar o arquivo recurso.txt com a correção que queremos aplicar, substituindo a frase "Este talvez seja o melhor recurso criado desde sempre!" para "Este talvez não seja o melhor recurso criado desde sempre! Mas é um dos mais legais!" no arquivo, adicionando-o ao git usando "git add recurso.txt", e depois comittando-o usando "git commit -m 'Little hotfix in a feature'". Veja:

11) Com o "bug" corrigido e comittado, podemos agora finalizar nossa hotfix branch e com isso juntá-la à branch master e à branch develop. Para fazer isso, basta usar o comando "git flow hotfix finish 0.1.1", que fará todas essas tarefas por nós e ainda criará uma tag para marcar a correção. Veja:

Novamente, como no caso do git flow release finish, estudado acima, o git flow abre o editor três vezes: Uma para editar o merge commit para o merge com a branch master, outra para editar a descrição da tag que será criada pelo Git Flow, e outra para o merge commit para o merge da branch master com a branch develop. Novamente, como recomendado acima, sugiro que você não edite o texto existente quando o Git Flow abrir o editor pela primeira e pela terceira vez, mas que acrescente uma boa descrição do que foi modificado quando o editor for aberto na segunda vez (ou seja, quando for para configurar a descrição da tag que o Git Flow irá criar).

Com isso, acho que já dá para ter uma bela introdução do que o Git Flow é capaz de criar. Na minha opinião, acho que esse modelo de organização de branches é ideal para trabalhar com projetos em equipe, pois permite que cada membro da equipe trabalhe em cada feature branch com maestria e ainda resolva bugs importantes quando eles forem encontrados.

Vale lembrar também que, neste tutorial, foram abordados apenas os comandos mais importantes que o Git Flow fornece, e que, assim como qualquer outra branch criada pelo Git, eles podem ser sincronizados livremente com sua equipe usando os sistemas de hospedagem de repositórios que abordamos no post anterior, sem precisar de mais nenhum suporte especial por parte desses sistemas. Maneiro, né?

Ah, caso tenha ficado alguma dúvida a respeito do Git Flow, sugiro a leitura do post que descreveu o modelo pela primeira vez, e também o resumo de dicas sobre o que cada comando faz criado por Daniel Kummer, que pode ser bem interessante para ajudar à fixar o que cada comando faz, por exemplo.

No mais, não se esqueça de deixar o seu comentário com sua opinião, critica, dúvida ou sugestão em relação ao post , e também de acompanhar o blog para não perder mais nenhuma dica sobre desenvolvimento e tópicos relacionados, pois apenas com sua ajuda e apoio que poderei trabalhar ainda mais em posts que abordam assuntos importantes para o desenvolvedor moderno, como esse, sobre o Git Flow.

Abaixo estão os links sobre a ferramenta:


Posts relacionados


51 respostas para “Git Flow - Uma forma legal de organizar repositórios git”

  1. Avatar de Fabiano Cacin Pinel
    Fabiano Cacin Pinel

    Bem completo seu post Fernando. Parabéns!

    1. Avatar de Fernando Jorge Mota

      Massa! Fico feliz que tenha curtido! volte sempre para não perder novos posts como esse. 🙂

  2. Avatar de Lucas Mauro

    Completo, como diz o Fabiano Cacin Pinel, e muito bem escrito.

    1. Avatar de Fernando Jorge Mota

      Valeu, Lucas! Fico feliz que tenha curtido!

      Abs.

  3. Avatar de Magno Santana
    Magno Santana

    Bem bacana, parabéns!!!

    Só uma coisa, ao finalizar a release só eh atualizado a branchs develop e master locais? Já que ele exclui as release features remotos deveria atualizar a develop e master tb..

    1. Avatar de Fernando Jorge Mota

      Opa Magno, valeu pelos elogios!

      Ele só atualiza o develop e master locais mesmo.

      Essa abordagem, pelo menos para mim, tem o ponto positivo de permitir que o desenvolvedor teste se está tudo OK antes de fazer o push..assim garante menos problemas. 😛

      Abs.

  4. Avatar de George
    George

    Até agora o melhor fluxo explicando o git-flow que eu já encontrei, parabéns!
    Tenho apenas uma dúvida, qual seria o fluxo pra quem cria algumas features, mas deseja entregar em uma release apenas uma dela?
    Ex: feature-1, feature-2 e feature-3 foram criadas. Cliente aprova a feature-2, qual seria o procedimento para criar uma release com a feature-2?

    1. Avatar de Fernando Jorge Mota

      Opa! Tudo bem? Valeu pelo elogio. Fico muito feliz em saber que você gostou do post. o/

      Então, isso é uma das coisas que o Git Flow não deixa exatamente..definido, pois se você criar uma release apenas com a feature-2 as outras features vão ficar possivelmente defasadas, dependendo de como o seu sistema está arquitetado.

      E é pelo fato de depender de como o sistema está arquitetado que a resposta varia. Para criar uma release com a feature-2, bastaria finalizar ela e criar a release correspondente. Quanto a isso não há dúvidas, uma vez que nada te impede de finalizar apenas uma feature branch e criar uma nova release a partir daí. Depois disso, para atualizar as demais features branches com o código novo da branch develop, é que as abordagens podem variar:

      Você pode fazer o merge (ou rebase, mas aí é da sua escolha, acredito) do develop novamente em casa feature branch antiga, de forma que o código nelas se mantenha atualizado. O que normalmente é o ideal pois permite que você desenvolva as features branch sempre com a última versão do código na branch develop;
      Ou você pode simplesmente ignorar e optar por fazer o merge no futuro, quando a branch for finalizada (no caso, deixar para o git resolver as diferenças entre a feature branch e o develop durante a operação de merge). Essa operação até funciona em determinados casos, mas é arriscada porque aumenta a chance de conflitos conforme a feature branch vai "envelhecendo" e a branch develop vai "avançando";

      Qual é a melhor opção? Bom, simplesmente varia. Eu já usei bastante a primeira em um projeto antigo, e funcionava bem, ainda mais quando uma feature branch se encontrava em espera devido à demora na resposta do cliente em relação a ela enquanto outras features branches iam sendo finalizadas. Logo, pelo menos trata-se de uma opção que funciona, mas, que, claro, poderia ser bem mais amigável do que é atualmente..

      Ficou claro?

      Abs.

  5. Avatar de Márcio Vennan
    Márcio Vennan

    Olá Fernando, meus parabéns pelo artigo, está muito bom!

    Gostaria de saber como seria o trabalho com pull request no Github e Git Flow. Nesse caso eu teria que solicitar um pull request de cada branch (release, feature, developer) do meu repositório pessoal com o repositório principal?

    1. Avatar de Fernando Jorge Mota

      Olá Márcio. Tudo bem?

      Muito obrigado pelo elogio!

      Não sei te responder precisamente esta pergunta pois nunca misturei as pull requests do Github com o que o Git Flow propõe. Acredito, entretanto, que o mais correto é não fazer pull request da branch de release nem da branch de develop, pois nesse caso você precisaria executar "git flow feature finish" e o merge seria feito por quem comittou a branch, e não por quem está revisando o código.

      Ou seja, para usar as duas ferramentas juntas, penso que o mais correto seria fazer pull request da branch de feature e, direto no Github, fazer o merge após os devidos reviews. Dessa forma, o reviewer ganha o poder de fazer o merge e não ocorre "git flow feature finish"..

      Talvez não seja a melhor solução, mas pelo menos permite um review mais tranquilo. Espero ter ajudado.

      Abs.

  6. Avatar de Alex Felipe
    Alex Felipe

    Oi Fernando tudo bem? Não tenho muito costume de comentar posts, porém, quando os mesmos são muito bons eu faço questão de parabenizar o autor... Portanto, meus parabéns, ficou incrível! Assinei o seu blog e acompanharei seus demais conteúdos. Aproveitando vou deixar uma dica em relação à escrita... Posts grandes como esse ficam melhores com tópicos feitos por h2 e h3 para que o leitor consiga identificar de uma forma melhor a que se refere tal parte do texto.

    Abraços.

    1. Avatar de Fernando Jorge Mota

      Olá Alex.

      Fico feliz que tenha curtido o post!

      Sobre a dica, eu normalmente separo as seções quando elas ficam claras o suficiente. No caso desse post, eu não tive muito o que separar pois considerei que a separação da lista (mostrando o que cada branch faz) e o respectivo tutorial já seriam o suficientes. Mas vou considerar sua dica para os próximos posts =)

      Abs. e qualquer outra dúvida, crítica ou sugestão é só mandar. 🙂

  7. Avatar de Raphael Negao
    Raphael Negao

    Quais as diferenças entre um repositório git e git-flow?

    1. Avatar de Fernando Jorge Mota

      Olá Raphael!

      Logo no primeiro post está descrito o que é o Git Flow:

      "Pensando nisso é que foi criado o Git Flow, um modelo de organização de branches criado por Vincent Driessen que mais tarde se tornou uma excelente extensão ao Git, permitindo seu uso de forma fácil com qualquer repositório git, e é sobre isso que vou falar hoje."

      Em resumo: Um repositório Git é um repositório de código versionado pelo Git (que eu expliquei neste post: https://fjorgemota.com/git-sistema-de-controle-de-versoes-distribuido/) - Já o Git Flow é apenas uma das muitas formas de organizar esse repositório para que o projeto fique mais tranquilo de gerenciar. =)

      Abs.

      1. Avatar de Raphael Negao
        Raphael Negao

        vlw,abrç

  8. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  9. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  10. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  11. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  12. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  13. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  14. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  15. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  16. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  17. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  18. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  19. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  20. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  21. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  22. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

  23. Avatar de Josué Henrique Ferreira
    Josué Henrique Ferreira

    Cara... Tá de parabéns....o post ficou muito bom. To estudando git flow pra aplicar na empresa que eu trabalho. Me ajudou muito cara ...vlw

    1. Avatar de Fernando Jorge Mota

      Olá Josué!

      Fico feliz que você tenha curtido o/

      Qualquer dúvida é só mandar. 🙂

      Abs.

  24. Avatar de William Florencio

    O texto, a explicação, os exemplos, o humor... tudo de bom!
    Muito obrigado mesmo!!!

    1. Avatar de Fernando Jorge Mota

      Valeu William!

      Fico muito feliz que tenhas curtido!

      Abs. =)

  25. Avatar de William Florencio

    Uma parada que não estou entendendo muito bem é que eu imaginei que os comandos para criação do git flow automaticamente "pushassem" tudo pro remoto. Isso facilitaria deu trabalhar em várias features ao mesmo tempo em pcs diferentes.
    Eu terei que fazer todos os pushs manualmente me cada branch? Ou só em algumas específicas?

    1. Avatar de Fernando Jorge Mota

      Opa William. Tudo certo?

      Os comandos do git flow não fazem "push" automaticamente para que seja possível a revisão do conteúdo onde foi feito o merge. Isso porque, embora o git flow faça o merge das branches, é possível que elas estejam modificadas no servidor "upstream" e por isso tenha que ser feito mais um "git pull" antes de efetivamente fazer o push. E desse "git pull", como sempre, podem surgir conflitos que no geral são mais simples para o desenvolvedor resolver.

      Sobre o push manualmente em cada branch..a resposta é sim. Mas, no geral, não são muitas branches a serem atualizadas (ou melhor, não espera-se que sejam atualizadas muitas branches numa só jogada). Por exemplo, quando você finaliza uma feature, ela é mergeada com o develop, então vale fazer push na develop e apagar a feature branch do servidor. Quando você cria uma nova release, basta fazer push da release branch correspondente, e assim vai. No geral, o pior caso que eu consigo imaginar é o caso das hotfixes branches, pois elas são mergeadas com o develop E com o master, além de criar uma tag. Nesse caso ficam por volta de duas branches mais uma tag a ser enviada (que é enviada apenas com a adição de um parâmetro no "git push"), sendo assim o caso com mais branches a serem atualizadas.

      Trabalhando sozinho, todo esse gerenciamento fica meio sem sentido, mas numa equipe esse processo tende a mais ajudar do que prejudicar. =)

      Abs.

  26. Avatar de Marlon Tiedt

    Primeiro, parabéns pelo post.

    Agora vamos as perguntas 😛

    Bonobo Git Server, é um bom servidor para Git? E se tem suporte ao Git Flow?
    Na sua opinião, qual seria a melhor forma de manter versões no caso que alguns arquivos foram congelados (exe) porém dll e afins continuam a ter melhorias?

    1. Avatar de Fernando Jorge Mota

      Olá Marlon, tudo bem?

      Primeiro, obrigado pelo elogio!

      Depois, as respostas para as suas perguntas:

      Não conheço o Bonobo, mas sei que o "servidor" não precisa suportar Git Flow explicitamente. O Git Flow, por si só, é só uma forma de organizar as branches, logo qualquer lugar onde você hospede o repositório Git deve servir..Aqui eu apresentei um pouco sobre algumas opções para hospedar repositórios Git que eu conheço https://fjorgemota.com/para-onde-enviar-meus-repositorios-git/ =)
      O ideal é que arquivos compilados, tais como ".exe" e ".dll" não entrem no repositório Git, mas sim arquivos de código fonte, que são então compilados e geram os respectivos arquivos ".exe" e ".dll". Isso possibilita o "push" e o "pull" de código entre diferentes usuários, além de possibilitar "merges" que permitem trabalho em paralelo (com padrões como o Git Flow organizando tudo);

      Fez sentido para você?

      Abs.

  27. Avatar de Paulo Linhares
    Paulo Linhares

    Fernando ótimo post, porém fiquei com uma dúvida. Quando eu tenho um submodule no meu repositório que é atualizado eu adicionaria essa mudança no branch hotfix ou no feacture? A atualização não do submodule não influencia em meu código por agora, só atualizei porque um dia talvez possa influenciar.

    1. Avatar de Fernando Jorge Mota

      Opa Paulo. Valeu pelo elogio!

      Depende do que a atualização desse submodule possui. Se for uma correção, entra em hotfix (pois nesse caso a correção vai direto pro develop E pro master), caso contrário, possivelmente entra em feature (pois nesse caso a mudança vai primeiro pro develop, e só depois de um release (contendo possivelmente outras features também) é que tal mudança vai pro master).

      Entendeu?

      Abs.

  28. Avatar de Bruno Azevedo
    Bruno Azevedo

    Obrigado pelo compartilhamento de conhecimento.

    Eu gostaria muito de saber se esse cenário é possível de reproduzir:

    1 - Crio um novo branch chamado branch_1 (uma cópia do diretório remoto);
    2 - Desenvolvo as implementações e alterações;
    3 - O gerente solicita que eu parasse o branch_1 para fazer uma nova tarefa;
    4 - Comento e adiciono as minhas alterações do branch_1;
    5 - Crio um novo branch chamado branch_2 (uma cópia do diretório remoto);
    6 - Desenvolvo as implementações e alterações do branch_2;
    7 - Adiciono, comento as alterações do branch_2;
    8 - Finalizo o branch_2;
    9 - Faço o merger do branch_2 com o repositório develop e envio para o servidor;
    10 - Faço o switch para o branch_1 e tudo volta a ser como era no branch_1.

    Eu tentei simular esse processo, mas o branch_2 manteve os arquivo do branch_1.

    1. Avatar de Fernando Jorge Mota

      Olá Bruno!

      Então, nesse caso o branch_1 e branch_2 seriam features, correto? Logo, caso correto, seu nome seria feature/branch_1 e feature/branch_2, respectivamente.

      Se você estiver usando o GIt Flow, isso é possível porque o git flow, ao criar a feature branch (usando git flow feature start branch_2, por exemplo), faz com que cada feature seja baseada no develop no estado atual. Observe que, se vocẽ não estiver usando git flow (algo que pessoalmente eu recomendo), esse erro pode ocorrer pois você pode estar baseando a branch_2 na branch_1, em vez de se basear no develop, e aí é natural que a branch_2 mantenha os arquivos da branch_1..

      Espero ter respondido sua pergunta.

      Abs.

  29. Avatar de Vaner Vainer Versore
    Vaner Vainer Versore

    Muito bom o post!!! Bem explicado, muito fácil o entendimento! Agora para mim só deu certo com mais um comando... Depois do "git flow release finish <versão>, tive de rodar "git push origin --tags"... É isso mesmo? Obrigado!

  30. Avatar de Luis Andre Costa Gouveia
    Luis Andre Costa Gouveia

    Parabéns pelo post,
    Gostaria de tirar umas duvidas, aqui no meu trabalho seguimos o seguinte fluxo, ainda não usamos o git flow, desenvolvemos uma nova feature quando terminamos "commitamos" para ser validado por outra pessoa, minha duvida é o seguinte, no git flow quando terminamos uma feature finalizamos ela e a mesma vai para o develop, caso algum bug daquela feature for encontrado é certo corrigir no branch develop ou teria algum outro fluxo a ser seguido?
    Outro cenário seria de que a feature tah tao errada que deve ser removida do develop e voltar para o desenvolvimento, qual fluxo seguir nesse caso?
    Aqui também usamos o Jenkins, qual seria o branch ou branches ideais para se usar no Jenkins?

    Obrigado.

    1. Avatar de Fernando Jorge Mota

      Opa Luiz! Valeu!

      Olha, normalmente correções podem ser aplicados diretamente na release branch (que é criada antes de partir para o master), não recomendaria mexer no develop diretamente não.

      Agora, se a mudança na feature estiver muito grande, acredito que vale fazer, na release branch mesmo, um "git revert" para remover a feature da versão, assim: git revert -m 1 <hash do merge commit criado pelo git flow feature finish>.

      No geral, eu indico que alterações na branch develop não sejam aplicadas diretamente pois é mais simples associar esse tipo de alteração a uma versão específica, o que não ocorre quando a alteração é feita diretamente na branch develop..

      Por fim, destaco que esse é só um palpite. O git flow acaba por não ser muito explícito sobre isso, e alterações a essa ideia são bem viáveis. =)

      Sobre o Jenkins, no geral as branches mais importantes são a branch develop e a branch master (que é para garantir que está tudo certo), então essas são as ideais de testar dependendo da quantidade de recursos que o Jenkins possui. Se tiver um pouco mais de recursos sobrando, vale testar também as release branches e as hotfixes branhes, que são intermediárias entre a branch master e a branch develop...Agora, se tiver realmente muito recurso sobrando, é ideal cobrir todas as branches para garantir que o código está bem estável, mas essas outras branches que eu mencionei são as principais, mesmo. 😛

      Abraço.

  31. Avatar de Winston Hanun Júnior
    Winston Hanun Júnior

    Gostei muito do seu artigo, continua nos ajudando, e meus parabéns, me ajudou bastante

  32. […] GitFlow […]

  33. Avatar de Rander
    Rander

    Muito legal o post. Ficou melhor explicado do que um curso online que fiz.

    Uma dúvida que tenho é a seguinte: como eu faço para integrar o pull-request com git-flow. Ou seja:

    Supondo que eu tenha uma equipe de desenvolvedores sendo que eu sou o responsável pelo projeto. Como eu faço para que os desenvolvedores só possam mesclar na branch develop ou na master por feature/hotfix/release branchs através da abertura de pull-request com code-review ?

  34. Avatar de Gabriel Novaes
    Gabriel Novaes

    Ótimo texto. Parabéns Fernando.
    Já coloquei na lista de leituras dos treinamentos da empresa.

  35. Avatar de Leandro da Silva Alves
    Leandro da Silva Alves

    Poxa, não ficou nenhuma dúvida! O post foi muito bem explicado e só aumentou a vontade de aprender mais.
    Muito obrigado!

  36. […] Fontes: https://danielkummer.github.io/git-flow-cheatsheet/index.pt_BR.html https://fjorgemota.com/git-flow-uma-forma-legal-de-organizar-repositorios-git http://taylorlopes.com/um-modelo-bem-sucedido-de-branches-no-git […]

Deixe um comentário

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.