7.3 KiB
Como abrir um Pull Request (PR)
Um pull request (PR) permite que você envie alterações do seu fork do GitHub para o repositório principal do freeCodeCamp.org. Depois de terminar de fazer alterações no código, você pode seguir essas diretrizes para abrir um PR.
[!NOTE] Seu PR deve estar em inglês. Veja aqui como contribuir com traduções.
Prepare um bom título para o PR
Recomendamos usar título e mensagens convencionais para commits e pull request. A convenção tem o seguinte formato:
<type>([escopo(s) opcional(is)]): <description>
Por exemplo:
fix(learn): testes para o desafio de ciclo do...while
Quando estiver abrindo um Pull Request (PR), você pode usar a referência abaixo para determinar o tipo, escopo (opcional) e a descrição.
Tipo:
Tipo | Quando selecionar |
---|---|
fix | Funcionalidade mudada ou atualizada/melhorada, testes, a explicação de uma lição, etc. |
feat | Somente se você estiver adicionando novas funcionalidades, testes, etc. |
chore | Mudanças não relacionadas ao código, testes ou explicação de uma lição. |
docs | Mudanças no diretório /docs ou nas diretrizes de contribuição, etc. |
Escopo:
Você pode selecionar um escopo a partir desta lista de etiquetas.
Descrição:
Escreva pouco (menos de 30 caracteres) e de modo simples. Você pode adicionar mais informações na caixa de descrição do PR e comentários.
Alguns exemplos de bons títulos de PRs seriam:
fix(a11y): contraste melhorado da barra de pesquisa
feat: adicionar mais testes aos desafios de HTML e CSS
fix(api,cliente): prevenir erros CORS no envio do formulário
docs(i18n): tradução para chinês da configuração local
Propondo um Pull Request
-
Uma vez que as edições tenham sido realizadas, será solicitado que você crie um pull request na página do GitHub do seu fork.
-
Por padrão, todos os pull requests devem ser feitos no repositório principal do freeCodeCamp, branch
main
.Certifique-se de que seu Fork Base está definido como freeCodeCamp/freeCodeCamp ao criar um Pull Request.
-
Envie o pull request da sua branch para a branch
main
do freeCodeCamp. -
No corpo de seu PR, inclua um resumo mais detalhado das alterações feitas e o motivo.
-
Será apresentado um modelo de pull request. É uma checklist que você deve seguir antes de abrir o pull request.
-
Preencha os detalhes como quiser. Essas informações serão revisadas e os revisores decidirão se seu pull request será aceito ou não.
-
Se o PR tem como objetivo resolver uma issue GitHub existente, então, no final do corpo da descrição de seu PR, use a palavra-chave Closes com o número da issue para automaticamente fechá-la, se o PR for aceito e dado merge.
Exemplo:
Closes #123
fechará a issue 123
-
-
Indique se você testou em uma cópia local do site ou não.
-
Isso é muito importante quando se está fazendo mudanças que não são apenas edições no conteúdo do texto como a documentação ou descrição de um desafio. Exemplos de mudanças que precisam ser testadas localmente incluem JavaScript, CSS ou HTML que podem mudar a funcionalidade ou aparência de uma página.
-
Se seu PR afeta o comportamento de uma página ele deve estar acompanhado pelo correspondente teste de integração Cypress.
-
Comentários nos pull requests
Parabéns! 🎉 por fazer um PR e muito obrigado(a) por contribuir.
Nossos moderadores vão dar uma olhada e deixar um comentário para você. Seja paciente com os outros moderadores e respeite o tempo deles. Todos os pull requests são revisados no tempo devido.
E como sempre, fique à vontade em perguntar na categoria 'Contribuidores' do fórum ou no chat dos contribuidores.
[!TIP] Se você vai contribuir com mais pull requests, recomendamos ler as diretrizes sobre fazer mudanças e sincronizá-las para evitar o apagamento de seu fork.
Conflitos em um pull request
Conflitos podem surgir porque muitos colaboradores trabalham no repositório, e as alterações podem afetar o seu PR, que está aguardando uma revisão e merge.
Na maioria das vezes, você pode não precisar de um rebase, porque nós comprimimos todos os commits. No entanto, se for solicitada uma rebase, é isso que você deve fazer.
Para funcionalidades e correções de erros comuns
Quando se está trabalhando em erros normais e funcionalidades na sua branch main
de desenvolvimento, você pode fazer um simples ajuste:
-
Faça um rebase na sua cópia local:
git checkout <pr-branch> git pull --rebase upstream main
-
Resolva quaisquer conflitos e adicione / edite commits
# Ou git add . git commit -m "chore: resolve conflicts" # Or git add . git commit --amend --no-edit
-
Faça um push das suas alterações para o PR
git push --force origin <pr-branch>
Para o próximo currículo e próximas funcionalidades
Quando você estiver trabalhando em funcionalidades para nossas próximas branches next-*
do currículo, você tem que fazer um cherry pick:
-
Certifique-se de que seu upstream esteja sincronizado com seu local:
git checkout main git fetch --all --prune git checkout next-python-projects git reset --hard upstream/next-python-projects
-
Faça o backup
a. Exclua sua branch local depois de ter feito um backup (se você ainda a tem localmente):
git checkout <pr-branch-name> # exemplo: # git checkout feat/add-numpy-video-question git checkout -b <backup-branch-name> # exemplo: # git checkout -b backup-feat/add-numpy-video-question git branch -D <pr-branch-name>
b. Ou apenas faça um backup da sua branch pr (se você não a tem localmente):
git checkout -b <backup-branch-name> origin/<pr-branch-name> # exemplo: # git checkout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
-
Comece do zero:
git checkout -b <pr-branch-name> next-python-projects git cherry-pick <commit-hash>
-
Resolva quaisquer conflitos e limpe, instale testes
npm run clean npm ci npm run test:curriculum --superblock=<superblock-name> # exemplo: # npm run test:curriculum --superblock=python-for-everybody
-
Se tudo estiver correto, faça um push ao PR
git push --force origin <pr-branch-name>