Nesta página é documentado o processo iTFLEX-flow, que é o nome dado ao padrão do fluxo de trabalho no git aqui na iTFLEX. Além disso, é documentado como criar e manipular as branchs de trabalho utilizando os comandos customizados do git da iTFLEX, por que e quando utilizar, para detalhamento de cada comando leia a página de comandos.

• ITFLEX flow - Descreve o fluxo de trabalho no git utilizado pela iTFLEX
• Processo de review - Descreve o processo e a peridiocidade de review
• Demais procedimentos GIT - Descreve outros procedimentos git utilizados pelo time, como rebase, review, etc.
  • Branchs
  • Rebase de um branch
  • Merge de um branch

FLOW

O iTFLEX flow adotado foi pensado como uma adaptação de dois fluxos bem populares: Git Flow e GitHub Flow. No entanto, foram definidas algumas alterações sobre as ideias originais dos fluxos citados.

O que ocorre dentro de cada branch/ticket é algo como:

Consulte a documentação de “Padrões de nomes/descrição” para entender o padrão de criação, nomenclaturas de branchs/tags e descrição de commits.

A branch master

A master será a branch onde a release, hotfix e bugs críticos serão mergeados.

Para cada funcionalidade/correção, deve ser criado um branch a partir do master. Nunca deve ser commitado diretamente no master.
O branch master deve estar atualizado antes de ser criado o branch. Todo branch deve usar os Padrões de nomes/descrição.

Bugs

Os bugs que ainda não estiverem em produção serão realizadas em branches à parte e posteriormente mergeadas na hotfix.

Já os bugs de maior prioridade identificados em produção (chamados de bugs críticos) serão corrigidos o mais rápido possível, sendo prioridade durante a sprint. Esses são amergeados direto na master.

cd ~/git/itflex

git checkout master
git up
git new bug-3304

Demais procedimentos GIT

Abaixo são ducumentados alguns procedimentos utilizados pelo time durante o desenvolvimento.

Branchs

As branches pessoais devem ser separadas em branches de frontend e backend.

Segue alguns exemplos:

story-46654-back
story-45775-front

Após finalizar as atividades do ticket deve ser aberto um merge request e por para review. Após o feito o review deve ser mergeado para a brach alvo, com um commit de squash e com a mensagem contendo a descrição do ticket.

Rebase de uma branch

Durante o desenvolvimento de uma funcionalidade/correção, pode ser necessário buscar alterações mais recentes do branch release. Para fazer isto, o processo utilizado é o rebase do branch em cima da release.

Para fazer o rebase, não pode haver alterações pendentes para serem commitadas. O processo de rabase é feito utilizando os seguintes comandos:

cd ~/git/itflex
git checkout release
git up
git checkout (na branch filha)
git rebase release 

Durante o rebase podem acontecer conflitos em alguns commits, que devem ser resolvidos. Para resolver os conflitos, verifique quais arquivos conflitaram com o comando git status, altere os arquivos para resolver os conflitos. Após resolvidos, devem ser utilizados os comandos abaixo para continuar o rebase:

git add .
git rebase --continue

Que dará continuação ao rebase, seguindo para o próximo commit. Podem ocorrer conflitos em mais de um commit, para cada conflitos realize este procedimento.

Após finalizar o rebase e resolver todos os conflitos (se houver algum), deve ser enviado para o servidor a branch atualizada. Como o rebase reescreve os commits do branch, para enviar as alterações para o servidor deve ser utilizado o comando git push -f, que força o git sobreescrever o branch remoto.

O rebase deve ser utilizado com cuidado, pois ele reescreve a árvore de commits do branch, se houver outras pessoas trabalhando no mesmo branch, pode ser apagado commits no servidor ao realizar o git push -f. O ideal é falar com quem estiver trabalhando no branch antes de realizar um rebase, para evitar problemas.

Se você ainda não entendeu muito bem o processo de rebase, você pode assistir a esse vídeo.

Merge de um branch

Após o review, correções e limpeza do histórico de commits, pode ser realizar o merge do branch. O merge é feito no modo fast forward, que mantém a ordem dos commits sequênciais na release. Para isto, deve ser feito um rebase da branch em cima da release ou da branch da versão, dependendo do tipo de atividade realizada.

Se o branch estiver linear com relação a release ou a brach alvo, no merge request vai aparecer o botão Merge, que deve ser clicado para realizar o merge do branch. Também é interessante marcar a opção de remover branch após o merge antes de clicar no botão de merge, para não ficar uma branch abandonada no servidor. Devemos sempre marcar a opções de squash dos commits para dar o merge.

Se a branch foi removida do servidor após o merge, ela pode ser removida do seu clone do repositório utilizando os seguintes comandos:

cd ~/git/itflex
git checkout master
git up
# git branch-clean-old
git bco

Que apaga branches locais que foram removidos do servidor.