Git Flow

O Gitflow, é um modelo alternativo de ramificação do Git, que consiste no uso de ramificações de recursos e várias ramificações primárias. Ele foi publicado pela primeira vez e popularizado por Vincent Driessen.

Branchs (novamente)

Um branch no Git, é simplesmente um ponteiro móvel, para um desses commits. O nome do branch padrão no Git, é main. Conforme você começa a fazer commits, você recebe um branch main, que aponta para o último commit que você fez. Cada vez que você faz um novo commit, ele avança automaticamente.

As branchs são capazes de criar uma réplica do mesmo arquivo, mantendo assim uma integridade temporal, até que haja uma necessidade de sincronização (merge), das versões de um mesmo arquivo. Considerando que, agora vamos querer realizar uma alteração em nosso arquivo.txt, mas sem modificar o que já existe no arquivo original, até que os demais membros concordem com a devida alteração. Para isso, vamos criar uma branch, denominada com nosso nome e realizar uma alteração no arquivo. Analise o código abaixo:

// criando uma nova branch
git branch seu-nome

// listando as branch do repositório
git branch

ou

git branch -r

// mudando para sua branch
git checkout seu-nome

Agora sim, estamos na branch que determinamos, para alterar o nosso arquivo.

Name Convention

Alguns projetos adotam padrões de nomenclatura de branchs, abaixo, temos algumas sugestões: Nomes de branches são compostos de três partes:

1 - Type ou categoria do branch. Os types podem ser os seguintes:

• docs: apenas mudanças de documentação;
• feat: uma nova funcionalidade;
• fix: a correção de um bug;
• perf: mudança de código, focada em melhorar performance;
• refactor: mudança de código, que não adiciona uma funcionalidade e também não corrige um bug;
• style: mudanças no código, que não afetam seu significado (espaço em branco, formatação, ponto e vírgula, etc);
• test: adicionar ou corrigir testes;
• chore: alterações triviais que não considera uma refatoração como: renomear uma variável, arquivo, reorganizar um Makefile;
• ci: ajustar as configurações do CI;
• build: ajustar as configurações do BUILD;

2 - O que o branch faz em si;

3 - Código da tarefa no Jira. Ex.: TASK-123.

Exemplos de alguns nomes de branches, que podem existir em nossa aplicação:

• feat-cadastro-veiculos-TASK-123.
• refactor-edicao-colaboradores-TASK-355.
• fix-busca-checklists-TASK-232.

Master (eterna)

• Inicia com o projeto;
• Ambiente produtivo: NÃO SE PODE TRABALHAR DIRETAMENTE NELA;
• Tem alteração, somente quando se encerra um Hotfix ou uma Release;
• Uma tag é gerada, indicando a versão do projeto a cada alteração.

Develop (eterna)

• Ambiente de desenvolvimento;
• Inicia com o projeto;
• É atualizada, quando uma feature ou release encerra;
• Não costuma trabalhar diretamente nela, mas podem haver exceções.

Feature (possui fim)

• Tem o seu início a partir da cabeça (commit mais recente) da develop;
• Representa uma história no scrum;
• Nomeia-se feature/NOME_DA_HISTORIA ou feature/ID_DO_REDMINE;
• É aqui que, a maioria dos commits serão executados;
• Quando a história for concluída, faz-se um merge dela, para a develop;
• Pode-se ou não excluir a branch, após o término.

Release (possui fim)

• Tem seu início a partir da develop, (devendo possuir todas as histórias que participarão da release);
• O ambiente de homologação, é sempre relativo ao último commit da branch (Jenkins pode assegurar isso com uma trigger);
• O código pode ser alterado diretamente na branch (Se a equipe de teste solicitar);
• Quando chegar na data programada, se não houver contratempo, realiza-se um merge tanto para a master quanto para a develop;
• Nomeia-se release/..* ou release/DDMMAA (Data prevista).

Hotfix (possui fim)

• Inicia a partir da cabeça da master;
• É utilizada para casos em que, um bug crítico foi encontrado;
• A decisão de se criar um hotfix, é quando não há tempo hábil de se esperar a próxima release;
• Seu tempo de correção deve ser menor, ao de um sprint;
• Na conclusão, é mergeado direto na master e na developer;
• Só será visível em homologação, na próxima release.

Mesclagem

Chegará um momento em que todas as versões de um mesmo arquivo precisarão se juntar e tornarem um só, existem duas maneiras mais convenientes em si realizar esta operação que são: Merge e Pull request.

Tanto um merge quanto um pull request, possuem a finalidade de consolidar o conteúdo distribuído em branchs, para uma versão final de cada arquivo alterado. A grande diferença está nas permissões, para a realização deste procedimento.

Merge

// primeiro você precisa garantir que está na branch receptora
git checkout sua-branch-receptora

// agora, você mesclará tudo o que modificou, para a branch receptora
git merge sua-branch-que-contem-as-modificacoes

// agora, será necessário enviar as alterações recebidas para o repositório remoto
git push

Pull Request

O pull request, é o pedido para que o repositório original ou uma branch do repositório original, faça a ação de pull (puxar), as atualizações do repositório fork ou de um branch do próprio repositório.