Sistema para controle de professores substitutos.
Qualquer tarefa ou problema deve ser reportado como uma Issue antes de executar qualquer coisa, seja a realização de uma tarefa, ou a correção de um problema.
Além disso, um desenvolvedor somente poderá trabalhar na Issue quando ela for classificada (bug, enhancement, etc) e/ou comentada pelo proprietário ou algum administrador do repositório.
Qualquer alteração na Wiki somente será feita depois de uma Issue específica para isso (veja item anterior) e de sua discussão/explicação por meio dos comentários da própria Issue.
O correto uso de git é fundamental. Assim, evitando problemas futuros, as branches master
e dev
estão bloqueadas
para push
e somente serão atualizadas por meio de pull requests
. Estes serão inspecionados por todos os
desenvolvedores e, caso algum problema seja encontrado, deverá ser corrigido antes de ser aceito - isso será feito tanto
nos comentários das issues quanto nos pull-request.
Assim, utilizaremos No Switch Yard (NoSY)
como workflow, além de usar um Git Branch Model específico
para criação de branches
e pull requests
.
Para facilitar um pouco esse entendimento, segue um exemplo prático de uso no NoSY e do Git Branch Model (com algumas padronização de nomes):
branch
a partir da dev
, substituindo ## pelo número da issue que foi documentada (com o hífen).$ git checkout -b [issue-##] remotes/origin/dev
commit
para marcar a evolução da correção.$ git add # arquivos
$ git commit # com os seus commits
Lembre-se que um commit
pode abranger mais de um arquivo, portanto adicione quantos arquivos forem necessários para
caracterizar o seu commit
.
branch
com a dev
.$ git checkout dev
$ git pull
$ git checkout [issue-##]
$ git rebase origin/dev
$ git push origin HEAD
A patir desse momento, a sua nova branch deve aparecer no repositório.
Aguarde o build e demais hooks avaliarem a branch
. Caso nenhuma falha seja encontrada, faça um pull-request
da
branch-##
para a dev
e aguarde os comentários da revisão - alguns hooks farão comentários automáticos neste
pull-request
e, portanto, as anotações deverão ser corrigidas e/ou explicadas.
Caso seja necessário alterar a sua branch
devido a alguma falha do build, dos hooks, ou dos comentários de revisão,
faça-os normalmente na sua branch issue-##
, sincronizando-a novamente ao final das mudanças e reenviando-a para o
repositório. Aguarde os resultados descritos no passo anterior e, se for o caso, repita todo este processo. Se um
pull-request já foi feito, não é necessário refazê-lo ou fechá-lo.
$ git checkout [issue-##]
$ git add # arquivos
$ git commit # com os seus commits
$ git rebase origin/dev
$ git push --force origin HEAD
A primeira linha de uma mensagem de commit
deve ser simples, precisa e significativa e, se possível, conter no máximo
50 caracteres. Se for necessária uma mansagem maior, resuma o problema corrigido na 1a linha e a partir da 3a
linha (terceira linha) da mensagem explique com mais detalhes o commit
, mantendo 120 caracteres por linha. Quando
pertinente e possível, utilize auto-referências às
issues e desenvolvedores, e mensagens com
palavras-chaves.
Alguns serviços automáticos foram associados a este repositório:
Muito cuidado ao manipular o hook do Codacy, pois ele utiliza uma variável de ambiente com uma chave secreta para enviar o relatório de code coverity para o dashborad. Se essa chave for pública, o dashboard ficará comprometido.