Home | Gerenciamento | Banco de Dados | Arquitetura | Desenvolvimento |
---|
Configuração | Mockups | Git |
---|
GitFlow
Modelo de organização de branches para o git. Estabelece algumas regras de nomenclaturas para tipos de branches enquanto e define o que cada tipo de branch faz.
Branches
BRANCHES PERMANENTES
Branches que vão ser mantidas durante todo o período de desenvolvimento do projeto. Elas devem ser protegidas para manter um histórico de alterações claro e conciso.
-
Master (branch em produção a ser distribuida para as demais branches, código já testado, que será entregue ao cliente)
-
Develop (branch para integração das alterações de desenvolvimento que já foram finalizadas. A partir daqui vai ser gerado o ambiente de desenvolvimento e features finalizadas devem enviar suas alterações para a develop.Deve sempre conter o código mais atual)
BRANCHES TEMPORÁRIAS
Branches temporarias devem ser criadas para cumprir um proposito e assim que esse proposito for concluído a branch deve ser apagada.
- Feature (branch utilizada para desenvolver novos recursos para o projeto. Esse tipo de branch é criado a partir da master, quando o novo recurso terminar de ser desenvolvido deve ser enviado para a develop). Nomenclatura feature/descricao_da_tarefa
- Bugfix (branch para correção de erros encontrados em produção. Esse tipo de branch tem por objetivo resolver o problema o mais rapidamente possível. Para isso a branch bugfix é criada a partir da master e deve ser utilizada para resolver o problema, assim que o problema for resolvido ela deve sofrer um merge para a master). Nomenclatura: bugfix/descricao_da_tarefa
Observações:
- A descrição da tarefa deve incluir o número da US (airtable).
- A cada commit realizado deve ser descrito brevemente, em português, o que foi desenvolvido.
- Anexar imagens da tela caso seja um bugfix
Ciclo de vida das Branches
Feature
- Criar uma nova branch a partir da master seguindo a nomenclatura /descricao_da_tarefa, onde o asterisco representa qualquer cadeia de caracteres.
- Realizar commits na branch afim de desenvolver a funcionalidade.
- Quando a Funcionalidade estiver completa realizar merge com a branch develop
Bugfix
- Criar uma branch a partir da branch master seguindo a nomenclatura bugfix/descricao_da_tarefa, onde o asterisco representa qualquer cadeia de caracteres.
- Realizar commits nessa branch com o objetivo de resolver o bug.
- Realizar o merge da bugfix com a branch master
Gerenciamento de branches no GitLab
Merge Request (MR)
Quando finalizamos o desenvolvimento de uma branch e queremos enviar suas alterações para outra branch precisamos criar um merge request. Omerge request é uma solicitação de merge que os Ages III e Ages IV vão avaliar para aprovar ou não esse merge. Sendo aprovado e não tendo conflito de commits o merge é feito automaticamente.
Criando um MR
Para criação de um MR basta você clicar em Merge Requests no menu principal e então depois em new merge request. Após isso, você seleciona a branch de origin e a branch de destino que você deseja submeter e então clica no botão comparar branches e continuar. Nessa tela então você vai definir o título de seu MR (de preferência o nome da tarefa ou User story) e então selecionar o template do MR conforme as imagens a seguir:
2. Selecione o template de NovaFeature
3. Dentro da descrição do MR vão aparecer alguns os campos que devem ser preenchidos
4. Dar assign para você no MR e marcar para deletar a branch
Após esses passos você clica em submit merge request.
Aprovação do Merge Request
O merge request só será aprovado se tiver ao menos dois Joinhas
Ciclo de Vida Gitflow - do MR à Publicação
Branchs fixas atuais:
• master
• develop
MR serão aprovados para as branchs respeitando a nomenclatura definida na imagem abaixo:
• bugfix/[número da feature] para master
• feature/[número da feature] para develop
Comandos básicos
Clonar o repositório
git clone [Link do repositório]
Criação de uma nova branch
git checkout -b [nome da branch]
Trocar entre branchs
git checkout [nome da branch]
Deletar uma branch
git branch -d [nome da branch]
Pegar modificações da branch remota
git pull [nome da branch remota]
Adicionar arquivos modificados
git add [nome do arquivo modificado]
Adicionar um commit
git commit -m "uma mensagem sobre as alterações feitas"
Adicionar um commit com mais de um autor
git commit -m "Refactor usability tests.
>
>
Co-authored-by: name <[email protected]>
Co-authored-by: another-name <[email protected]>"
Observação: o símbolo > significa uma linha vazia
Adicionar as alterações a branch remota
git push [nome da branch remota]