DEV Community: Rodrigo Santana

Gitflow: entenda quando e como você deve utilizar

Rodrigo Santana — Sat, 05 Feb 2022 04:48:02 +0000

Ao utilizar o Git para gerenciar versões de um projeto é preciso decidir o fluxo de trabalho (workflow), que irá estabelecer funções bem específicas para diferentes branches e definir quando e como elas devem interagir. Existem diversos fluxos de trabalho consolidados e que podem ser utilizados nos projetos. Neste artigo será abordado sobre o Gitflow, criado por Vincent Driessen.

É comum as pessoas acharem que o Gitflow é um padrão que deve ser estabelecido em qualquer projeto que utilize Git, o que não é uma verdade. Não existe um fluxo de trabalho perfeito onde todos devam seguir, você deve decidir o modelo com base principalmente nas características de implantação do seu projeto.

Como utilizar?

Branches básicas e de longa duração

O Gitflow inicia com as seguintes branches básicas

Main (antiga master): contém o código-fonte de produção
Develop: contém o código-fonte que irá integrar todas as alterações desenvolvidas para o ciclo do próximo lançamento

Branches de suporte

A partir das branches básicas são criadas as branches de suporte. Tais branches podem ser do tipo feature, hotfix ou release. A imagem abaixo, ilustra a origem para cada tipo de branch e o destino.

Feature: são ramos para desenvolvimento de novos recursos do sistema ou correções de bugs não emergenciais, criados a partir da branch develop. Após o desenvolvimento, as alterações são mescladas em direção a branch develop (origem).
Hotfix: são ramos para desenvolvimento de correções emergenciais, criados a partir da branch master. Após o desenvolvimento, as alterações são mescladas em direção as branches master (origem) e develop, para que a correção esteja disponível para as novas features.
Release: são ramos utilizados para preparação do lançamento da próxima versão de produção. Nelas são permitidas alterações pontuais. Fazendo tais alterações na release branch, a branch develop fica livre para receber novos recursos da próxima versão. São criadas a partir da develop e, após a validação da release, devem ser mescladas em direção a develop (origem) e a master. O "merge back" na develop é importante, pois atualizações críticas podem ter sido adicionadas a release branch e precisam estar acessíveis a novos recursos.

Pontos importantes

As branches master e develop são linhas contínuas, ou seja, se mantém durante todo o tempo de projeto.
As branches de suporte são temporárias, após concluir o propósito e as alterações retornarem para a origem, tais ramos devem ser descartados.
Não há merge da develop em direção a master diretamente, sempre utiliza-se as release branches.
As branches que realizam merge em direção a master devem gerar tags, como será visto na parte prática desse artigo.

Praticando

Existem ferramentas para auxiliar no dia a dia quanto a este modelo, você não precisará se preocupar com a origem a qual a nova branch será criada, para onde deve ocorrer a mesclagem quando o trabalho for concluído e se é necessário criar uma tag. A ferramenta irá gerenciar isso para você. Neste artigo será apresentado uma extensão para linha de comando, como é uma extensão, tal recurso não é instalado nativamente com a instalação do Git.

Considere o link abaixo e as orientações para realizar a instalação:

https://github.com/nvie/gitflow/wiki/Installation

Após a instalação:

Crie um diretório em seu computador com o nome "gitflow"
Acesse tal pasta utilizando o git bash
Execute: git flow init
Altere os prefixos se preferir ou pressione enter para cada interação para manter o padrão.

Criando uma feature branch

Para iniciar o desenvolvimento de uma nova feature basta executar o comando abaixo:

git flow feature start <NOME_FEATURE>

Para esta prática, considere NOME_FEATURE igual a "cache-provider". Após executar, veja que o prefixo configurado no git flow init foi concatenado com "cache-provider". As ações internas envolveram criar uma nova branch baseada na develop e um checkout em tal branch.

Para demonstração do desenvolvimento da feature "cache-provider" execute os seguintes passos:

touch cache-provider.js (cria um arquivo em branco chamado cache-provider.js no diretório)
git add cache-provider.js (adiciona o arquivo na área de preparo/staging para o próximo commit)
git commit -m "adding a cache provider" (realiza um commit que inclui o arquivo recém criado)
git flow feature finish cache-provider (indica que a feature foi concluída e pode ser mesclada para develop)

Como visto na imagem acima, também não é necessário informar o prefixo na hora de encerrar uma feature. Ao concluir uma feature as ações internas que ocorrem são:

Mesclagem da feature em direção a develop
Remoção da branch criada feature/cache-provider
Checkout na branch develop

Se você estiver desenvolvendo um novo recurso de forma colaborativa, seria interessante publicar a feature após cada commit da seguinte forma:

git flow feature publish <NOME_FEATURE>

Criando uma hotfix branch

Quando um problema emergencial surge e não há a possibilidade de aguardar a próxima release pode-se utilizar hotfix. Para isso, basta executar o seguinte comando:

git flow hotfix start <NOME_HOTFIX>

Para esta prática, considere NOME_HOTFIX igual a "template-fix". É importante observar que este tipo de branch foi criado baseado na master. Logo após a criação da branch é feito um checkout no ramo recém criado.

Para demonstração do desenvolvimento da hotfix execute os seguintes passos:

touch template-fix.js
git add template-fix.js
git commit -m "template bug fix"
git flow hotfix finish template-fix

Será aberto o editor padrão para solicitar uma definição da tag e dos commits de merge (para develop e para a master). Você deve informar, obrigatoriamente, ambas as descrições (os merges já possuem uma descrição padrão que você pode manter, mas a tag precisa ser informada).

Observe que várias ações foram promovidas:

Houve um merge da branch hotfix em direção a master e develop
Uma tag foi criada
A branch de hotfix foi deletada
Houve um checkout novamente para a branch develop.

Criando uma release branch

A correção emergencial já consta nas duas branches básicas master e develop, contudo a feature "cache-provider" ainda não está na master. Qualquer novo recurso ou correção não emergencial é promovido em produção através de release branches. Para isso execute o comando abaixo:

git flow release start <NOME_RELEASE>

Neste momento, foi realizado checkout na branch do tipo release que foi criada a partir da branch develop. Este ramo permite correções antes de ser mesclado na branch master, o que justifica um merge de volta para develop. Nessa prática, não será realizado nenhum tipo de correção, por isso basta executar:

git flow release finish <NOME_RELEASE>

Observe que várias ações foram promovidas:

Houve um merge da branch release em direção a master e develop
Uma tag foi criada
A branch de release foi deletada
Houve um checkout novamente para a branch develop.

Guia

A imagem abaixo ilustra bem como você pode utilizar esta extensão para Gitflow por linha de comando.

Fonte: https://danielkummer.github.io/git-flow-cheatsheet/index.pt_BR.html

Pontos de atenção

Qualquer novo recurso ou bug não emergencial deve ser mesclado com a branch develop somente quando este estiver confirmado na próxima release. Isso porque a próxima versão que será promovida em produção é criada a partir da branch develop. Se a cada release há a necessidade de remover commits pois esses foram bloqueados por algum motivo, isso certamente irá gerar um overhead muito grande para a equipe de desenvolvimento
- Uma alternativa que pode minimizar esse problema é a utilização de feature toogles, quando possível
É interessante possibilitar testes na própria ramificação de recurso ou bug não emergencial, para que qualquer erro ou um entendimento equivocado seja resolvido antes da integração com a branch develop
Se não há ferramentas e processos, que possibilitem os testes acima, então os testes serão realizados diretamente na branch develop. Neste caso, é muito importante que todo o time esteja comprometido em agir prontamente para qualquer erro reportado. Lembre, essa versão é a que será implantada em produção na próxima release
Mudanças de prioridades podem ocorrer, porém se constantemente é necessário remover commits da develop, talvez o Gitflow não seja o melhor fluxo de trabalho para este projeto
Antes de definir o Gitflow como o modelo que será implantado, estude outros fluxos de trabalho disponíveis. Dependendo das necessidades você pode considerar outros mais simples e que envolvam menos passos e preocupações

Considerações finais

Após a leitura sobre diversos artigos sobre Gitflow, um assunto que considero bastante polêmico no que tange sua utilização, o Gitflow parece funcionar bem para produtos com lançamentos feitos uma vez a cada poucas semanas, porém quando a necessidade é implantar em produção constantemente, talvez seja interessante avaliar outros fluxos de trabalho

Vale destacar a própria nota de reflexão do Vincent Driessen, criador do Gitflow:

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

Quer aprender mais sobre Git? Aprenda no mais novo curso de Git - Básico ao avançado

Entenda as diferenças entre os tipos de merge no Git: Fast-forward X Three-way

Rodrigo Santana — Wed, 29 Dec 2021 01:44:13 +0000

Pré-requisitos

Conceitos básicos sobre Git

Como todo sistema de controle de versão (VCS) o Git dispõe de recursos de criação e união de branches. Para mesclar uma branch na outra, você pode considerar merge ou rebase. Nesse artigo será apresentado o que é um merge, as estratégias envolvidas fast-forward e three-way e o que são conflitos e quando podem ocorrer.

O que é um merge?

Merge é uma opção muito comum e útil em repositórios que possuem mais de uma branch além da principal. Se é necessário fundir uma branch em outra, o merge pode ser uma opção.

Vale lembrar que uma branch no Git, é um ponteiro para um commit, que será a última versão de tal ramificação. Por exemplo, considere a sequência, a qual inicialmente existe um commit inicial "first commit" na branch principal.

Em seguida, um novo commit "setup" é realizado.

Após isso, um contribuidor João cria uma nova branch "login" a partir do commit setup. Isso significa que neste momento ambas as branches apontam para a mesma versão do repositório e que possuem o mesmo histórico, porém são dois ramos totalmente independentes. Qualquer nova versão em uma branch não afetará a outra e vice-versa. Observe o resultado de um novo commit "creating login feature" na branch "login".

Note que o rótulo da branch login passou a referenciar este último commit, mas o rótulo da branch master ainda está apontando para o commit "setup". Ou seja, a branch login está a um commit à frente em relação a branch master.

E se João desejar integrar os commits feitos na branch login na branch master, como fazer isso? Uma das opções, é através de merge.

Merge fast-forward

João decide integrar a branch login na branch master. Para isso ele retorna para a branch master com o comando abaixo:

git checkout master

Em seguida executa o comando:

git merge login

Note que nessa situação, a única tarefa necessária que o Git precisou realizar foi mover o rótulo da branch master para o commit "creating login feature". Por isso, o nome dessa estratégia é fast-forward (em português avanço rápido), pois é simplesmente uma alteração de ponteiro.

Merge three-way

Agora considere que antes de João integrar a branch login na branch master, uma outra contribuidora Maria promoveu um novo commit "creating user feature" na branch master.

Nesse caso, uma tentativa de merge não terá o mesmo resultado do exemplo anterior. Isso porque um commit foi realizado na branch master após a criação da branch login. Então não basta mover o ponteiro, há duas versões que precisam ser combinadas, que são o "creating user feature", commit que só existe na branch master e "creating login feature", commit que só existe na branch login. Veja a seguir o resultado de um merge nessa situação.

Observe que foi gerado um novo commit "Merge". Tal commit foi gerado de forma automática pelo Git, que uniu as alterações envolvidas nos dois ramos em uma nova versão do repositório. Veja também que este novo commit possui dois pais e o histórico do repositório não é mais linear. A estrutura que representa o histórico linear ou bifurcado no Git pode ser definida como DAG (Directed Acyclic Graph ou Grafo Acíclico Dirigido).

Conflitos

No exemplo anterior, ao realizar um merge com a estratégia three-way, o Git conseguiu gerar um commit de merge automaticamente, pois as alterações que precisavam ser combinadas não conflitavam. Entretanto, as duas branches poderiam ter alterado as mesmas linhas de um mesmo arquivo e nesse caso, o Git não pode determinar automaticamente o que está correto e é necessário decisões humanas.

Os conflitos afetam apenas o contribuidor que conduz a mesclagem, o resto da equipe não tem conhecimento do conflito. O Git marcará o arquivo como conflitante e interromperá o processo de fusão. É responsabilidade desse contribuidor resolver o conflito.

Por exemplo, imagine que Joao além de ter criado um novo recurso login, tenha alterado a linha 4 de um arquivo global do sistema. Maria também, além de ter criado o novo recurso de usuários, alterou a linha 4 desse mesmo arquivo. Qual alteração deve prevalecer no commit de merge, a alteração de Maria? Ou a alteração de João? O Git não pode determinar isso de forma automática, João que realizou a mesclagem que irá avaliar. Talvez a alteração de João seja melhor, como ele também pode considerar que a alteração de Maria faça mais sentido ou ainda, a alteração de ambos se complete.

Vale destacar que conflitos só surgem em mesclagens com a estratégia three-way. Merge fast-forward nunca irá gerar um conflito, pois não há histórico divergente a ser combinado. É somente mudança de ponteiro.

No fast-forward

Considere novamente a seguinte situação:

Neste caso, quando foi executado um merge da branch login em direção a branch master, o Git assumiu a estratégia fast-forward e moveu o rótulo da branch master para o commit "creating login feature". Porém, é possível forçar a utilização de uma estratégia three-way, fazendo que o Git crie um commit de merge. Para isso basta incluir a opção --no-ff (no fast-forward) no comando merge:

git merge --no-ff login

Note que esta era uma situação típica de fast-forward, porém com a opção --no-ff o Git foi forçado a gerar um commit de merge. Isso pode ser útil, ocasionalmente, caso você precise marcar pontos de mesclagem no histórico. Você só deve ter em mente que um histórico com muitos commits de merge pode torná-lo confuso e de difícil compreensão. Já em situações que o merge seria pela estratégia three-way, você não pode forçar um fast-forward.

Merge sem checkout, é possível?

Nos exemplos vistos, antes de uma ação de merge, foi realizado um checkout na branch master. Em todos os casos o objetivo era um só, incluir os commits exclusivos da branch login na branch master, que era a branch corrente com o checkout.

Neste contexto, uma pergunta que pode surgir é sobre a possibilidade de fazer uma mesclagem entre duas branches, que não são a branch corrente. A resposta para esta dúvida pode ser respondida pelo texto a seguir, retirado diretamente da fonte:

"...Você não pode mesclar uma branch B na branch A sem fazer o checkout de A primeiro, caso isso resulte em uma mesclagem sem fast-forward (three-way). Isso ocorre porque uma cópia de trabalho é necessária para resolver quaisquer conflitos em potencial. No entanto, no caso de mesclagens fast-forward, isso é possível , porque tais mesclagens nunca podem resultar em conflitos, por definição..."

Conclusão

Como vimos, um merge pode ser executado de duas formas: por estratégia fast-forward ou three-way. A primeira, quando possível, será a melhor opção pois mantém um histórico linear e está livre de resolução de conflitos, pois envolve somente alteração de referência. Já a segunda, além de gerar um histórico bifurcado, com commits adicionais de mesclagem, ainda está suscetível a resolução de conflitos. Esses commits adicionais podem prejudicar a leitura do histórico. Ao menos que você utilize um --no-ff, o Git irá definir a estratégia de merge de acordo o histórico das duas branches envolvidas na mesclagem.

Quer aprender mais sobre esta ferramenta essencial para desenvolvedores de software? Aprenda no mais novo curso de Git - Básico ao avançado

Entenda conceitos básicos sobre Git

Rodrigo Santana — Tue, 07 Dec 2021 01:22:37 +0000

Cada vez mais as empresas investem em projetos de tecnologias para facilitar negócios, automatizar tarefas, difundir informações entre vários outros propósitos. Geralmente uma das primeiras etapas de desenvolvimento de projetos é definir como você irá controlar e manter as alterações que irão ocorrer ao longo do desenvolvimento. Existem algumas ferramentas de mercado com esta finalidade.

Neste artigo você irá aprender conceitos básicos sobre Git, uma ótima opção para este propósito. Entre os controles de versões disponíveis no mercado, o Git é o mais utilizado, principalmente em projetos open source. Esta ferramenta armazena todas as alterações ocorridas nos arquivos do seu projeto permitindo regressões para um estado anterior. Além disso, permite que várias pessoas trabalhem simultaneamente no mesmo projeto e até nos mesmos arquivos.

CVCS x DVCS

Existem diversos sistemas de controle de versão no mercado. Há sistemas de controle de versão centralizado, o CVCS (Centralized Version Control System), como Subversion (SVN), CVS e Perforce. E há sistemas de controle de versão distribuído, o DVCS (Distributed Version Control System), como Git, Mercurial e Bazaar.

O CVCS possui um repositório central do projeto, geralmente localizado em um servidor, que contém todo o histórico do projeto. Qualquer membro do projeto que desejar colaborar, precisará fazer um checkout de uma versão do projeto. Essa operação irá baixar uma cópia da versão selecionada para a máquina do contribuidor, porém nesta máquina não existirá o histórico do projeto. O histórico só existe no repositório central e por isso, vários comandos são executados remotamente, o que gera uma dependência de conexão à internet e explica o motivo da maioria dos comandos serem mais lentos, dado que existe o overhead da rede.

O DVCS por outro lado não depende necessariamente de um repositório central. Isso porque os contribuidores podem clonar repositórios existentes ou criar seus próprios repositórios locais. Esse processo de clonagem baixa todo o conteúdo remoto e também o histórico completo do projeto. Por isso, a maioria das operações podem ocorrer localmente, sem depender de conexão com internet, o que resulta em uma velocidade maior comparado aos CVCSs. Pelo histórico estar distribuído, há uma quantidade maior de backups comparado a um CVCS, já que nesse, o histórico só existe no repositório central. Se o repositório central estiver localizado em um servidor interno vulnerável, isso poderia comprometer todo o histórico do projeto.

Local x remoto

No Git é possível criar o próprio repositório através do comando git init, que irá criar o diretório oculto ".git". Porém, é importante que esse repositório esteja armazenado remotamente, isso porque tal opção pode servir como backup do repositório. Para armazenamento remoto você pode considerar as plataformas de hospedagem para repositórios Git, como Bitbucket, GitLab e GitHub ou até mesmo um servidor próprio. Caso ocorra um problema irreparável em seu computador, você estará seguro pois o repositório também existe na opção que você está utilizando.

Além disso, é interessante que o projeto esteja disponível remotamente para possibilitar o trabalho colaborativo. Outras pessoas podem baixar uma cópia do repositório (clone), realizar modificações e enviar (push) tais alterações novamente para o repositório remoto. Quando for necessário atualizar o repositório porque outro contribuidor submeteu novas versões, basta atualizar o repositório local puxando as modificações envolvidas (pull).

As três áreas

O Git possui 3 áreas principais: a área de trabalho, a área de preparo e o repositório.

A área de trabalho (Working Directory) é o checkout de uma versão do projeto. Corresponde aos arquivos e diretórios visíveis e alteráveis.

Ao realizar qualquer alteração, seja mudança em arquivos existentes, como inclusão de novos arquivos, antes de gerar uma nova versão, você primeiramente deve adicionar tais alterações para a área de preparo (Staging Area).

Por fim, você poderá executar um commit, que irá considerar todas as alterações que estiverem na área de preparo. Isso irá produzir uma nova versão no histórico do projeto.

Commits

O histórico de versões no Git é formado por objetos de commit. Esse histórico é baseado em uma estrutura denominada DAG (Directed Acyclic Graph). Um commit é uma imagem do atual estado do seu repositório. Ou seja, é uma "foto" de como está cada arquivo em um determinado momento. É possível retornar para qualquer commit feito no passado.

O commit está associado a uma hash SHA-1, tal hash possui metadados como autor, data de criação, mensagem e commit pai. Todos esses metadados mais o conteúdo do arquivo formam o SHA-1 do commit, que é imutável. Ou seja, não pode ser alterado. Por isso, qualquer comando utilizado com o propósito de alterar algo relacionado ao commit, irá resultar em um novo SHA-1.

Branches

Em teoria, uma branch é uma ramificação de um projeto. Na prática, no Git, uma branch é uma referência para um commit. A branch principal de um projeto chama-se “master”. Porém, há iniciativas para alterar este nome a longo prazo, devido ao termo “master” ser considerado racista.

Há vários benefícios na utilização de branches como:

Rápido e fácil de ser criada: 1 arquivo que contém uma referência
Permitem a experimentação: Os membros da equipe podem isolar seu trabalho para que ele não afete os outros até que o trabalho esteja pronto
Suporte a várias versões: As ramificações permitem suporte a várias versões do projeto simultaneamente
Permitem processos de revisão de arquivo: As ramificações permitem incluir processos de revisão de arquivos

Considere a imagem abaixo como um exemplo de um repositório com mais de uma ramificação

Na imagem acima, uma ramificação do projeto é criado a partir da versão "first commit". Nesse instante, cada ramo terá seus próprios commits enquanto não houver algum mecanismo de fusão entre os ramos. Os principais mecanismos de fusão são: merge ou rebase.

A referência HEAD

A HEAD é uma referência que normalmente vai apontar para a branch corrente. Já uma branch, como visto anteriormente, é uma referência para um commit. Este commit por sua vez, será a última versão de tal ramificação. Para um melhor entendimento, considere a sequência a seguir.

Inicialmente existe somente uma branch chamada master que aponta para o commit "first commit". Também existe uma referência chamada HEAD que aponta para a branch master, ou seja, indiretamente aponta para o commit "first commit". Aqui existe uma referência simbólica, que ocorre quando uma referência aponta para outra referência.

É criado uma nova branch chamada xpto a partir do commit "first commit".

Ao realizar checkout na nova branch, o Git altera a referência HEAD para apontar para a branch xpto. Isso significa que qualquer novo commit será aplicado na ponta dessa nova branch. Veja o resultado de um commit "creating service" na branch xpto.

Observe que se outro commit for realizado, o rótulo da branch xpto irá referenciar o novo commit. Para a referência HEAD não há mudanças, ela permanecerá apontando para a branch corrente.

Agora para gerar novos commits na branch principal, basta realizar primeiramente um checkout na branch master.

Pronto, agora qualquer novo commit será aplicado na branch master. Veja o resultado de um commit "hotfix" nesta situação.

Conclusão

Como vimos, o Git é um sistema de controle de versão distribuído que possui diversos recursos para auxiliar na gestão de alterações. É uma ferramenta muito utilizada principalmente no contexto de software e que também permite que um grupo de pessoas possa trabalhar de forma colaborativa no mesmo projeto, editando e criando novos arquivos.

Quer aprender mais sobre esta ferramenta essencial para desenvolvedores de software? Aprenda no mais novo curso de Git - Básico ao avançado

DEV Community: Rodrigo Santana

Gitflow: entenda quando e como você deve utilizar

Como utilizar?

Branches básicas e de longa duração

Branches de suporte

Pontos importantes

Praticando

Criando uma feature branch

Criando uma hotfix branch

Criando uma release branch

Pontos de atenção

Considerações finais

Entenda as diferenças entre os tipos de merge no Git: Fast-forward X Three-way

O que é um merge?

Merge fast-forward

Merge three-way

Conflitos

No fast-forward

Merge sem checkout, é possível?

Conclusão

Entenda conceitos básicos sobre Git

CVCS x DVCS

Local x remoto

As três áreas

Commits

Branches

A referência HEAD

Tags

Conclusão