7.3 KiB

Raw Blame History

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>
```

7.3 KiB Raw Blame History