|
|
|
|
|
|
|
|[Home](home)|[Sprints](sprints)|[Requisitos](requisitos)|[Arquitetura](arquitetura)|[Configuração](configuracao)|[Mockups](mockups)|[Banco de Dados](banco_dados)|[Instalação](instalacao)|[Gerência de Projeto](Gerenciamento do Projeto)|[Horários Disponiveis](horarios)| [Git](git)
|
|
|
|
|---|---|---|---|---|---|---|---|---|---|---| |
|
|
\ No newline at end of file |
|
|
|
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
## GitFlow
|
|
|
|
|
|
|
|
#### O que é?
|
|
|
|
|
|
|
|
GitFlow é um fluxo de trabalho no Git que auxilia na organização e versionamento de código. As definições tratadas ao longe deste documento de aplicam as repositórios de Fronted e Backend.
|
|
|
|
|
|
|
|
#### Como funciona?
|
|
|
|
|
|
|
|
O Git Flow trabalha com duas branches principais, a Develop e a Main, que duram para sempre; e duas branches de suporte, Feature e Hotfix, que são temporários e duram até realizar o merge com as branches principais.
|
|
|
|
|
|
|
|
Então, ao invés de uma única branch Main, esse fluxo de trabalho utiliza duas branches principais para registrar o histórico do projeto. A branch Mai armazena o histórico do lançamento oficial, e a branch Develop serve como uma ramificação de integração para recursos.
|
|
|
|
|
|
|
|
#### Modelo GitFlow
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Branches protegidas
|
|
|
|
|
|
|
|
#### Main
|
|
|
|
|
|
|
|
Principal branch, aqui é onde temos todo o código de produção. Todas as novas funcionalidades que estão sendo desenvolvidas, em algum momento, serão mescladas ou associadas a Master.A branch é protegida e só pode ser alterada a partir de Merge Requests vindo diretamente da branch develop ou de branches de hotfix. Apenas AGES III e IV podem fazer merge dos MRs e realizar alterações nessa branch.
|
|
|
|
|
|
|
|
#### Develop
|
|
|
|
|
|
|
|
É a branch onde fica o código do próximo deploy. Ela serve como uma linha do tempo com os últimos desenvolvimentos, isso significa que ela possui funcionalidades que ainda não foram publicadas e que posteriormente vão ser associadas com a branch Main. Essa branch é protegida para modificação que não seja através de Merge Requests. Qualquer AGES pode criar um MR para a brach de desenvolvimento.
|
|
|
|
|
|
|
|
## Branches não protegidas
|
|
|
|
|
|
|
|
#### Feature
|
|
|
|
|
|
|
|
São branches utilizadas para o desenvolvimento de funcionalidades específicas. É importante saber que essas branches são criadas sempre a partir da branch develop. Portanto, quando finalizada, elas são removidas após realizar o merge com a branch develop.
|
|
|
|
|
|
|
|
#### Fix
|
|
|
|
|
|
|
|
É uma branch para correção de bugs identificados ainda em desenvolvimento. Após o merge com a develop elas são removidas.
|
|
|
|
|
|
|
|
#### Hotflix
|
|
|
|
|
|
|
|
É uma branch criada a partir da master para realizar correções imediatas encontradas no sistema em produção. Quando concluída, ela é excluída após realizar o merge com as branches main e develop.
|
|
|
|
|
|
|
|
## Padrão para criação de branches
|
|
|
|
As branches criadas para desenvolvimento das funcionalidades pelas squads devem seguir o padrão de acordo com seu objetivo:
|
|
|
|
|
|
|
|
Tags para os tipos de alterações:
|
|
|
|
|
|
|
|
* **feature** - Nova funcionalidade
|
|
|
|
* **fix** - Correção de defeito
|
|
|
|
* **hotflix** - Correção de bug em produção
|
|
|
|
|
|
|
|
`feature/NUMERO_TASK`
|
|
|
|
|
|
|
|
Exemplo: `feature/12`
|
|
|
|
|
|
|
|
## Padrão para as mensagens de commit
|
|
|
|
Os commits deverão ter um padrão em suas mensagens para facilitar o entendimento da equipe no que foi desenvolvido:
|
|
|
|
|
|
|
|
`"Descrição breve do commit - Autores (caso realizado em equipe)"`
|
|
|
|
|
|
|
|
Exemplo: `"Cadastro de instituições - Duda, Julia e Will"`
|
|
|
|
|
|
|
|
**OBS:** Caso as atividades do commit tenham sido realizadas individualmente não é necessário informar os autores, porque a única pessoa envolvida será quem está subindo o commit.
|
|
|
|
|
|
|
|
## Padrão para abertura de Merge Request
|
|
|
|
Os merge requests também devem seguir um padrão de criação:
|
|
|
|
|
|
|
|
O Title deve ser escrito `UserStory - Título do Card no Trello` e na Description deve ser informado o link para o card.
|
|
|
|
Exemplo:
|
|
|
|
```
|
|
|
|
Title: US17 - Aceitar Requisição no feed de requisições
|
|
|
|
Description: link do card do Trello
|
|
|
|
```
|
|
|
|
|
|
|
|
## Critério de aceite de Merge Requests (MR)
|
|
|
|
|
|
|
|
* Branch testada
|
|
|
|
* Branch atualizada com a DEV
|
|
|
|
* Arquitetura Respeitada
|
|
|
|
* Código Limpo
|
|
|
|
|
|
|
|
## Comandos básicos
|
|
|
|
|
|
|
|
* clonar um repositório:
|
|
|
|
`git clone ADICIONAR URL`
|
|
|
|
* verificar o status do repositório:
|
|
|
|
`git status`
|
|
|
|
* CRIAR uma nova branch:
|
|
|
|
`git checkout -b <branch desejada>`
|
|
|
|
* ALTERNAR para uma branch:
|
|
|
|
`git checkout <branch desejada>`
|
|
|
|
* add arquivos alterados e dar um commit na branch:
|
|
|
|
`git commit -a -m 'adicionei um novo rodapé [issue 53]'`
|
|
|
|
* primeira vez a enviar os dados para o repositório.
|
|
|
|
`git push origin <branch desejada>`
|
|
|
|
* reenviar os dados para o repositório.
|
|
|
|
`git push`
|
|
|
|
* baixar os dados do repositório.
|
|
|
|
`git pull`
|
|
|
|
* fazer um merge em duas branch's.
|
|
|
|
`git merge <nome da branch>` |
|
|
\ No newline at end of file |
