| id | title |
|---|---|
contributing |
Guia de Contribuição |
Agradecemos pelo interesse em contribuir com o projeto! Para isso, basta seguir os passos abaixo:
- Fazer o fork do repositório, caso seja um colaborador externo.
- Criar issues, em conformidade com o nosso template.
- Criar uma ou mais branches para trabalhar nas issues levantadas, de acordo com nossa política de branches.
- Seguir nossa política de commits durante o desenvolvimento.
- Ao final, submeter um pull request, também de acordo com nosso template. Simples assim!
Segue-se o fluxo de trabalho descrito pelo Gitflow, representado pelo diagrama abaixo:
Dessa forma, existem as seguintes categorias de branches:
Branch de produção, com a versão estável mais atual do projeto. Bloqueada para commits e pushs, pode ser interagida apenas através de pull requests provenientes da devel, hotfix branches ou release branches.
Branch de desenvolvimento, agrupa o trabalho de outras branches com o objetivo de se criar uma versão de release para ser submetida à master. Também é bloqueada para commits e pushs, devendo ser modficada através de pull requests provenientes das feature branches.
Branches criadas a partir da devel, para o desenvolvimento de uma funcionalidade específica. Idealmente, uma feature branch deve ser referente à uma issue cadastrada no repositório, para melhor acompanhamento e rastreamento do projeto. Ao final do desenvolvimento, deve-se submeter um pull request visando a devel. Se as modificações forem aceitas com sucesso, a branch deve ser apagada.
Feature Branches devem seguir o padrão x_nome_da_issue, com x sendo o número da issue correspondente no repositório.
Branches criadas a partir da master, para a correção rápida de bugs em produção. Ao final, as atualizações submetidas devem ser integradas tanto à master quanto à devel.
Hotfix Branches devem seguir o padrão hotfix_x_nome_da_issue, com x sendo o número da issue que identifica o bug a ser corrigido.
Branches criadas a partir da devel, servem para a preparação de uma release do projeto. Deve conter tarefas apenas relacionadas a essa release, como correção de bugs ou refino de alguma funcionalidade já implementada. Funcionalidades novas não devem ser desenvolvidas nessa branch. Com a release preparada, deve-se integrar a branch à master.
Release Branches devem seguir o padrão release/numero_de_versao, identificando a versão do produto que será entregue naquela release.
Para um fluxo de trabalho sem grandes inconvenientes, recomenda-se manter as branches pessoais de desenvolvimento (features, hotfixes) sempre atualizadas. Antes de se submeter um pull request, deve se garantir que a branch possui todas as alterações mais recentes de sua branch de origem. Para isso, deve se utilizar os seguintes comandos:
git checkout branch_de_trabalho
git pull --rebase branch_de_origem # devel para features, master para hotfixes
git push origin branch_de_trabalho
Os commits devem possuir mensagens sucintas e descritivas, explicando as modificações realizadas. Devem ser escritos em inglês, no imperativo. Por exemplo:
git commit -m "Add API routing for User service."
Ao invés de:
git commit -m "Adding API routing for User service."
Ao se desenvolver funcionalidades utilizando a técnica de pair programming, deve se atribuir autoria a ambos os colaboradores. Para isso, deve se utilizar a tag co-authored-by do Github, através dos seguintes passos:
- Após adicionar todos os arquivos modificados, executar o commit sem flags adicionais:
git commit
- Isso abrirá o editor de texto padrão configurado para o Git. Digite a mensagem de commit, e após duas linhas em branco, adicione a co-autoria. Exemplo:
Add repo policies
Co-authored-by: Felipe Hargreaves <[email protected]>
Co-authored-by: Mariana Picolo <[email protected]>
Dessa forma o commit será contabilizado pelo Github como sendo realizado pelos dois contribuidores, gerando um registro mais detalhado de participação.