Explicação Básica do Git Flow e GitHub Flow no Terminal

Com o passar dos anos, sempre desenvolvi alguns textos e sempre tive vontade de postá-los em um blog, mas nunca levei essa ideia adiante. No entanto, com o TabNews, estou conseguindo publicar esses conteúdos que criei, e este é mais um deles.

Este conteúdo foi desenvolvido pensando em um grupo de estudos que eu organizava na minha faculdade. O texto foi escrito há algum tempo e pode conter alguns erros, mas o conteúdo é de grande utilidade.

Espero que seja útil para vocês e deixem qualquer feedback que acharem necessário. Obrigado por ler :)

Workflows

Github Flow & Git Flow:

A ampla utilização de repositórios git veio acompanhada de diversos modelos de
padronização, seja padronizações nas mensagens dos commits, na utilização das
branches entre outros aspectos.

Alguns dos flows (as padronizações) mais utilizadas e conhecidas são: Git Flow
e o Github Flow. Vejamos as principais características de cada flow:

• Git Flow

  É um workflow focado no desenvolvimento de softwares de grande escala, com muitos
  desenvolvedores, desenvolvimento de diversas features em paralelo e a manutenção
  de uma versão já no ar e aberto ao público.

  Quando temos todas essas demandas é necessário um controle rigoroso do código,
  prevenindo a inutilização do código no ar, e esse controle é feito seguindo um
  padrão de branches.

  Por padrão, existem duas branches principais: main e develop. A branch main
  é onde o código em produção (no ar) está e é a versão que o usuário verá. E a
  branch develop é onde os desenvolvedores propriamente desenvolvem novas features:

  
  

  Fonte: Atlassian Bitbucket

  A partir da branch develop criam-se as branches de feature, seguindo o nome
  padrão 'feature/<nome da funcionalidade>'. E ao finalizar a funcionalidade
  mergeamos para a branch develop e podemos deletar a branch de feature:

  
  

  Fonte: Atlassian Bitbucket

  Assim conseguimos desenvolver cada funcionalidade nova paralelamente sem
  interferir nas outras. Quando temos algumas novas funcionalidades e desejamos
  criar uma nova versão do nosso software devemos fazer o seguinte procedimento:

  • Cria um fork (ramificação dessa branch) da branch develop e nessa branch faz
    os últimos ajustes. Essa branch é chamada release e é nomeada da seguinte
    forma: 'release/<nova versão do software>'.

  • Quando terminamos a preparação da branch release podemos mergear ela na branch
    main e na branch develop, daí podemos deleta-la.

  Veja o esquema abaixo:

  
  

  Fonte: Atlassian Bitbucket

  Ainda existem as branches de hotfix, elas são branches derivadas da branch
  main, normalmente utilizadas para solucionar bugs ou problemas no software
  aberto ao público:

  
  

  Fonte: Atlassian Bitbucket

  Note que uma branch hotfix deve ser mesclada tanto na branch main quanto na
  branch develop para manter as duas atualizadas.

  Além da utilização de branches, o git flow utiliza tags (rótulos) para 'marcar'
  pontos importantes da história do repositório, geralmente as suas versões.

  A utilização do git flow pode ser difícil de maneira pura, por isso podemos
  instalar a ferramenta git-flow. Na distribuição Ubuntu de Linux basta rodar:

  ~$ apt install git-flow
  

  Assim obteremos acesso a comandos como: git flow init, git flow release start,
  git flow hotfix start, etc.

  Nem todos os detalhes do git flow puderam estar listados aqui. Para mais
  informações pesquise na internet sobre.

• Github Flow

  Pode ser considerada uma versão simplificada do git flow. É amplamente utilizada
  em projetos de pequena escala e com poucos desenvolvedores (de 2 a 5, por exemplo).
  Possui um workflow mais simplificado e pode ser explicado no esquema abaixo:

  
  

  Fonte: SvanBoxel (Github user)

  Esse workflow segue os seguintes passos:

  • crie um fork da branch main chamada 'feature/<nome da funcionalidade>'
  • desenvolva e commit suas alterações na branch criada
  • quando finalizar suas modificações crie um pull request
  • os responsáveis pelo repositório devem aceitar ou recusar seu pull request
  • caso aceito, seu código será mergeado e entrará no código em produção

E portanto, temos um ambiente de desenvolvimento organizado de acordo com nossas
necessidades. É importante notar que existem outros workflow e não podemos
classificá-los entre 'melhor' ou 'pior', cada um depende de seu contexto e
aplicação.