Introdução
Uma comunicação efetiva busca sempre ser clara e concisa, ou seja, permite que toda a informação seja transmitida e que não aconteça de forma confusa. A fim de atingir esse objetivo, nosso grupo adotou algumas práticas para nomenclatura de branches e commits, bem como padronizou a forma como será realizada "pull requests" e "merge commits" no nosso repositório remoto de acordo com as regras do exercício do tira-dúvidas.
Nomenclatura
Todas as nomenclaturas devem utilizar o kebab-case, escrevendo em letras minúsculas e com separações indicadas por hífen.
Branches
Acordado pelo grupo de conter a estrutura "primeiro-nome-do-criador/conteúdo".
Commits
Acordado pelo grupo de seguir o padrão definido pelo guia de estilo Git do repositório "stoneco-best-practices".
Regras
Para o projeto estamos seguindo todas as regras exigidas como requisitos de acordo como especificados em regras do projeto e adotamos alguns pontos em consenso com a equipe. Dentre todas regras destacamos as seguintes:
- é proíbido realizar commits e push na branch main;
- deve-se abrir uma Pull Request sempre que for integrar algum trabalho na branch main;
- somente após todos os colaboradores revisarem a Pull Request que pode ser realizado o merge na origin/main;
- todos os commits devem estar verificados/assinados (preferencialmente com chaves GPG) para que uma Pull Request seja aprovada;
- após concluir uma Pull Request deve-se apagar a topic branch;
- em caso de conflitos durante o merge deve-se colocar a Pull Request em draft, realizar rebase e resolver localmente;
Pull Requests
Ao abrir uma Pull Request deve ser as seguintes etapas:
- ir para branch main, realizar fetch e merge com a origin/main;
- retornar a sua topic branch e realizar rebase main; *obs. resolver os conflitos caso exista.
- realizar o commit assinado;
- fazer push com repositório remoto; será que o push obrigatoriamente será forçado?
- abrir a Pull Request; *obs. lembrar de marcar-se com autor e solicitar que os demais colaboradores sejam revisores.
- todos os revisores devem aprovar ou solicitar explicitamente quais correções devem ser feitas;
- somente após todos as correções terem sido realizadas e todos os revisores terem aprovado que pode realizar o merge na main *obs. caso na hora de realizar o merge o gitHub acusar algum conflito a pull request deve ir para o estado de draft e retomar para o passo 1.
Descrição do Repositório
Repositórios devem possuir uma descrição símples do seu objetivo. No caso do nosso repositório, essa descrição está localizada no arquivo README.md em sua pasta raiz.
Código de Conduta
Todos os membros do grupo se comprometeram a seguir alguns valores em relação à forma como será realizado o trabalho e a comunicação durante a tarefa:
- sendo receptivo
- sendo participativo
- sendo respeitoso
- sendo colaborativo
- sendo comunicativo e pedindo ajuda
Todos os membros do grupo condenam qualquer tipo de ato que incite discriminação, violência, segregação ou que possa causar constrangimento devido a comentários negativos direcionados a uma ou mais pessoas envolvidas ou não no projeto.
Referências
Referências para a construção dessa página: