Home | Escopo | Processo | Design/Mockups | Configuração | Arquitetura | Gerência | Código | BD | Qualidade | Frontend | Backend | Analytics |
---|
Definições de Gerenciamento de Projeto
Descrição
- Esta seção apresenta como a gerência do projeto foi feita, como o time está organizado, como trabalha, e quais são os processos de desenvolvimento.
Sumário
- EAP do Projeto
- Organização do Time
- Matriz de Responsabilidade
- Plano de Comunicação
- Plano de Riscos
- Git Workflow
EAP do Projeto
- Texto
Organização do Time
- Texto
Matriz de Responsabilidade
- Texto
Plano de Comunicação
- Texto
Plano de Riscos
- Texto
Git Workflow
- O Gitflow é um modelo alternativo de ramificação do Git que consiste no uso de ramificações de recursos (features) e várias ramificações primárias (
main
edevelopment
).
Branches
- Cada branch relacionada à features será criada a partir da branch development. Nos tópicos abaixo será explicado as nomenclatura que serão utilizadas para o desenvolvimento.
Nomes
- O nome da branch será em inglês e deve seguir o padrão feature/nome-da-feature, onde os nomes das features podem ser encontrados no Trello. Quando for necessário fazer alguma correção, o prefixo utilizado deverá ser fix/nome-da-feature.
Criação
- Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch development antes de criar uma branch nova:
git pull origin development
Depois da execução desse comando é necessário criar a Branch, para isso, execute o seguinte comando:
git checkout -b <nomeDaBranch>
Commits
-
Após criar a sua branch de desenvolvimento, faça as alterações necessárias no código e commite as mudanças:
-
Para adicionar as mudanças é possível utilizar dois comandos:
O comando git add .
, faz com que todas as alterações que foram feitas localmente sejam commitadas no repositório remoto.
git add .
O comando git add <nomeDoArquivo>
, faz com que apenas as alterações do arquivo informado seja commitado no repositório remoto.
git add <nomeDoArquivo>
- Após adicionar as alterações é necessário commitar elas usando o comando
git commit-m"comentario-do-commit"
git commit-m"comentario-do-commit"
-
O comentário deve descrever o que foi alterado no código e deverá ser em inglês.
-
Após, se for o primeiro commit dessa branch:
git push --set-upstream origin nome-da-branch
- Caso contrário utilize:
git push
Importante: Sempre envie seus commits para o repositório remoto após realizar o seu trabalho, assim os outros desenvolvedores terão sempre as ultimas atualizações do código.
Merge Requests
-
Depois da sua issue ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de development.
-
Antes de abrir a MR certifique-se que, não irá ocorrer conflitos da sua branch com a
development
, para isso, siga os seguintes passos:
git checkout development
git pull
git checkout <nome-da-branch>
git merge development
- Resolva os conflitos caso ocorra, após resolvê-los, envie as alterações para o Gitlab:
git push
Criando o Merge Request
- A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request siga os seguintes passos:
- Selecionar a branch de origem (sua branch de desenvolvimento);
- Selecionar a branch de destino (branch development);
- Selecione Compare branches and continue;
- Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
- Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
- Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
- Na seção Assignee, marcar o responsável pela tarefa.
- Na seção Reviwers, marcar os AGES 3 (Arthur, Martin e Sofia).
Documento de Continuação
- Texto