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 12
    • Issues 12
    • 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
  • Gendrify ID
  • wiki
  • Wiki
  • processo

Last edited by Lucas Tashan Porto Ramos Oct 01, 2023
Page history
This is an old version of this page. You can view the most recent version or browse the history.

processo

Processo de desenvolvimento

Esta seção é dedicada a apresentar o processo de desenvolvimento do time.

Git workflow

Branchs

Nomes

Padrão para o nome de branchs:

<tipoDeTrabalho>/<nomeDaPasta>-<nomeDoArquivo>

Exemplo para o nome de branches:

feature/components-InputText // para novos desenvolvimentos

bugfix/components-InputText // para correções

Para a criação de components, screens, containers e services, adotamos o inglês como linguagem padrão, sempre lembrando de utilizar o estilo PascalCase (primeiras letras maiúsculas).

Criação

Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de voltar para a branch main e executar o seguinte comando antes de criar uma branch nova:

git checkout main

git pull origin main

Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:

git checkout -b <nomeDaBranch>

Assim que criar a branch, é necessário fazer um push para garantir que a mesma estará remota:

git push --set-upstream origin <nomeDaBranch>

Pronto! Agora você já pode começar a programar na sua Branch.

Commits

Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de commit e push

Salvando Localmente

Para garantir que apenas o código necessário para funcionamento da tarefa lembre-se de realizar o comando add apenas nos arquivos essenciais para a tarefa:

git add <nomeDoArquivo>

Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:

git commit -m 'descrição da tarefa em português'

Não hesite em realizar vários commits, assim podemos ter docuemntado e salvo vários estados do desenvolvimento

Salvando Remotamente

Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando push:

git push

Merge Requests

Depois de uma task 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 desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:

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:

Obs: Escolha a Source branch(a branch que utilizou para a implementação do código) e a Target branch. Clique em Compare branches and continue.

A partir daí:

  1. Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
  2. Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
  3. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
  4. Na seção Assignee, selecione Assign to me para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
  5. Em Milestone selecione a Sprint em que a tarefa foi realizada;
  6. Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em Submit Merge Request.

Revisando o Merge Request

A revisão de merge request pode ser realizada por qualquer desenvolvedor, mas é preciso da aprovação de pelo menos um AGES III ou AGES IV para que a mesma seja incorporada na dev.

Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração.

Clone repository
  • arquitetura
  • banco_dados
  • codigo
  • design_mockups
  • escopo e cronograma
  • Home
  • processo