Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GiftReminder
  • Wiki
  • Wiki
  • gerencia

Last edited by Leonardo Vargas Soares Nov 13, 2024
Page history
This is an old version of this page. You can view the most recent version or browse the history.

gerencia

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 e development).

Fluxo_GIT

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:
  1. Selecionar a branch de origem (sua branch de desenvolvimento);
  2. Selecionar a branch de destino (branch development);
  3. Selecione Compare branches and continue;
  4. Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
  5. Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
  6. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
  7. Na seção Assignee, marcar o responsável pela tarefa.
  8. Na seção Reviwers, marcar os AGES 3 (Eduardo Ballico, Leonardo Vargas Soares e Pedro Vieira).

Documento de Continuação

  • Texto
Clone repository
  • Banco de Dados
  • Configuracao
  • Design_Mockups
  • Git Workflow
  • arquitetura
  • escopo
  • gerencia
  • Home
  • qualidade