GIT Workflow

Fluxos de Trabalho no Sistema de Versionamento GIT

Índice

- Centralized Workflow

- Feature Branch Workflow

- Gitflow Workflow

- Forking Workflow

Fonte: https://www.atlassian.com/git/workflows

Contato: dpasqualin@gmail.com

Diego Giovane Pasqualin

Forking Workflow

Gitflow Workflow

Centralized Workflow

Feature Branch Workflow

Feature branch worflow + branches especiais + tags;

Branches especiais: develop, release, hotfix;

Existe um repositório "oficial", mas cada desenvolvedor tem seu próprio repositório remoto, um fork do original;

Cada nova funcionalidade é desenvolvida em seu próprio branch;

O merge para o master é feito através de merge requests;

Possui somente o branch "master", todos os desenvolvedores publicam diretamente nele;

A revisão de código é feita a posteriori;

Maria começa uma nova funcionalidade

Repositório central é inicializado

Vantagens

Branch develop

Cada desenvolvedor pode utilizar o workflow que preferir;

Os desenvolvedores não precisam ter acesso de escrita no repositório oficial;

Muito comum no desenvolvimento de grandes aplicações open source;

Considerando somente os branches develop e branches feature o fluxo é o mesmo do Feature Branch Workflow, com o develop do Gitflow Workflow sendo análogo ao master do Feature Branch Workflow;

$ git checkout -b issue/1234

$ git status

$ git add <some-file>

$ git commit

$ git push -u origin issue/1234

Maria faz um pull (merge) request

Todos clonam repositório central

Fork -> Alteração -> Merge Request

Branch Release

git clone ssh://user@host/path/to/repo.git

Os interessados em colaborar com um projeto fazem um fork (cópia) dele, modificam criando funcionalidades e/ou corrigindo bugs, posteriormente submetem um merge request do seu repositório para o repositório oficial.

Os branches do tipo release representam releases futuras e são nomeados na forma: release/X.Y.Z;

Não recebem novas funcionalidades, apenas correções de bugs;

Quando pronto, um merge do branch release é feito com o master e com o develop (o release pode ter recebido correções que devem ser visíveis as novas features no develop);

Após merge, o release/X.Y.Z deve ser deletado;

Desenvolvedores revisam código

João aplica uma nova funcionalidade

Branch hotfix

No C3SL

$ git status # Ver mudanças locais

$ git add <file> # Adicionar arquivo

$ git commit <file> # Submeter arquivo

# Enviar para repositório remoto

$ git push origin master

Os projetos do C3SL são a união de um dos fluxos de trabalho anteriores (fortemente recomendado Feature ou Gitflow workflow). O Forking Worflow só é utilizado para contribuir ou permitir contribuições da comunidade externa.

Contém correções de bugs que não podem aguardar o lançamento de uma próxima release.

O merge de um hotfix é o único feito diretamente com o master, além do branch develop (e release, se existir);

Maria tenta aplicar uma nova funcionalidade

Branch master

Maria aplica correções e funcionalidade é adicionada ao master

Todo merge para o master recebe uma tag com o nome do branch release de origem, ou um acréscimo mínimo de versão quando originado de um branch hotfix

$ git push origin master

error: failed to push some refs to '/path/to/repo.git'

hint: Updates were rejected because the tip of your current branch is behind

hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')

hint: before pushing again.

hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Se o branch master for protegido somente os masters do repositório podem fazer o merge, caso contrário a própria Maria pode fazê-lo.

Maria reconstrói sua base local

$ git pull

# Git pausa a operação quando encontra conflito.

# Resolva conflitos de cada commit de forma independente

$ git add <file> # Para resolver o conflito

$ git rebase --continue # Seguir para próximo commit

$ git rebase --abort # Cancela toda a operação desde git pull

Maria aplica nova funcionalidade

$ git push origin master