Como fazer o primeiro pull request
Cada comando de git, do fork ao pull request, com o que faz e o erro mais comum.
O primeiro pull request em 6 comandos
Git 2.55 · nomes de exemplo
| Ordem | Comando | O que faz | Copiar |
|---|---|---|---|
| 01 | git clone https://github.com/seu-usuario/projeto.git | Baixa o seu fork para o computador. passo 2 | |
| 02 | git remote add upstream https://github.com/dono-do-projeto/projeto.git | Registra o projeto original como upstream. passo 2 | |
| 03 | git switch -c corrige-link-quebrado | Cria a branch e passa a trabalhar nela. passo 3 | |
| 04 | git add README.md | Marca o arquivo para o próximo commit. passo 5 | |
| 05 | git commit -m "docs: corrige o link quebrado do README" | Grava o commit com a mensagem. passo 5 | |
| 06 | git push -u origin corrige-link-quebrado | Envia a branch para o seu fork. passo 6 |
Depois, no site do GitHub: Compare & pull request (passo 7). Troque os nomes no passo a passo abaixo e os comandos saem com os seus.
Passo a passo, do fork ao pull request
9 passos e 19 comandos de terminal, cada um com o que faz e o erro mais comum. Escreva os seus nomes e todos os comandos se reescrevem.
Seus comandos, com os seus nomes
Seus nomes: seu-usuario · dono-do-projeto/projeto · corrige-link-quebrado
Passo 01Achar a tarefa e fazer o fork
Comece por um projeto que você já usa e por uma tarefa pequena. O fork é a sua cópia do projeto na sua conta do GitHub, e é nela que você tem permissão de escrita.
- Abra o projeto no GitHub e leia o README, o CONTRIBUTING e o CODE_OF_CONDUCT, se existirem.
- Veja se há commits recentes e se as issues e os pull requests recebem resposta.
- Procure uma tarefa pequena, como um erro de digitação ou uma issue com o rótulo "good first issue" ou "help wanted". Comente nela que você vai trabalhar antes de começar.
- Na página do projeto, clique em Fork, escolha a sua conta como dona e clique em Create fork.
Este passo acontece no site do GitHub e vem da documentação oficial; não foi testado aqui.
Fontes deste passoEsconder as fontes
Fonte: GitHub Docs: Finding ways to contribute (sem data na página; CC BY 4.0 (conteúdo); MIT (código)); Open Source Guides: How to Contribute (sem data na página; CC BY 4.0); GitHub Docs: Fork a repository (sem data na página; CC BY 4.0 (conteúdo); MIT (código)) · abertas em (reconferência semanal registrada)
Clonar o seu fork e ligar o projeto original
Traga o seu fork para o computador e registre o original como upstream, para buscar as novidades dele depois.
git clone https://github.com/seu-usuario/projeto.git
O que faz: Baixa o seu fork, com todo o histórico, para uma pasta com o nome do projeto. O remoto origin já aponta para ele.
Erro comum: A pasta já existe, de uma tentativa anterior.
O Git responde: fatal: destination path 'projeto' already exists and is not an empty directory.
Como sair: Entre na pasta que já existe (cd) ou apague-a, ou clone com outro nome de pasta no fim do comando.
cd projeto
O que faz: Entra na pasta do projeto. Todos os comandos seguintes rodam de dentro dela.
git remote add upstream https://github.com/dono-do-projeto/projeto.git
O que faz: Registra o projeto original com o apelido upstream.
Erro comum: Você já registrou o upstream antes.
O Git responde: error: remote upstream already exists.
Como sair: Rode git remote -v para ver o que está registrado. Para trocar o endereço, use git remote set-url upstream <endereço>.
git remote -v
O que faz: Lista os remotos. Confira: origin é o seu fork e upstream é o projeto original.
Erro comum: Você está fora da pasta do projeto.
O Git responde: fatal: not a git repository (or any of the parent directories): .git
Como sair: Entre na pasta do projeto com cd e rode de novo.
Os 4 comandos deste passo, em ordem.
Fontes deste passoEsconder as fontes
Fonte: GitHub Docs: Fork a repository (sem data na página; CC BY 4.0 (conteúdo); MIT (código)); GitHub Docs: Contributing to a project (sem data na página; CC BY 4.0 (conteúdo); MIT (código)) · abertas em (reconferência semanal registrada)
Criar uma branch para a sua mudança
Trabalhe numa branch própria, nunca na main. Assim a main do seu fork continua igual à do projeto e o pull request leva só a sua mudança.
git switch -c corrige-link-quebrado
O que faz: Cria a branch e já passa a trabalhar nela. É o mesmo que git checkout -b corrige-link-quebrado.
Erro comum: Já existe uma branch com esse nome.
O Git responde: fatal: a branch named 'corrige-link-quebrado' already exists
Como sair: Troque de branch com git switch corrige-link-quebrado, ou escolha outro nome.
Fontes deste passoEsconder as fontes
Fonte: Pro Git: Branches em poucas palavras (sem data na página; CC BY-NC-SA 3.0); GitHub Docs: Contributing to a project (sem data na página; CC BY 4.0 (conteúdo); MIT (código)) · abertas em (reconferência semanal registrada)
Fazer a mudança e conferir o que mudou
Edite os arquivos no seu editor e salve. Depois peça ao Git um retrato do que mudou antes de guardar.
git status
O que faz: Mostra a branch atual e quais arquivos foram alterados ou ainda não estão no Git.
Erro comum: Aparece "nothing to commit": o Git não viu mudança nenhuma.
O Git responde: nothing to commit, working tree clean
Como sair: Você esqueceu de salvar o arquivo no editor, ou editou outra cópia da pasta.
git diff
O que faz: Mostra, linha a linha, o que mudou e ainda não foi marcado com git add.
Erro comum: Aparece vazio depois de você rodar git add.
O Git responde: (sem saída)
Como sair: O git diff só mostra o que ainda não foi marcado. Depois do git add, use git diff --staged.
git diff --check
O que faz: Aponta espaços sobrando no fim das linhas, um engano comum que o Pro Git manda conferir antes do commit.
Erro comum: O comando lista linhas e termina com código de saída diferente de zero.
O Git responde: README.md:3: trailing whitespace.
Como sair: Apague os espaços do fim da linha indicada e salve de novo.
Os 3 comandos deste passo, em ordem.
Fontes deste passoEsconder as fontes
Fonte: Pro Git: Contribuindo com um projeto (sem data na página; CC BY-NC-SA 3.0) · abertas em (reconferência semanal registrada)
Guardar a mudança em um commit
O commit é um ponto de salvamento com uma mensagem. Primeiro você marca o que entra nele (git add); depois grava (git commit).
git add README.md
O que faz: Marca o arquivo para entrar no próximo commit. Troque README.md pelo arquivo que você mudou.
Erro comum: O nome do arquivo está errado, ou você está na pasta errada.
O Git responde: fatal: pathspec 'README.txt' did not match any files
Como sair: Confira o nome (e as letras maiúsculas) com git status ou ls, e rode de novo.
git commit -m "docs: corrige o link quebrado do README"
O que faz: Grava o commit com a mensagem entre aspas. O gerador de mensagem deste site monta o texto no padrão Conventional Commits.
Erro comum: É o primeiro commit neste computador e o Git não sabe quem você é.
O Git responde: Author identity unknown
Como sair: Rode os dois comandos que o próprio Git mostra, sem o --global se quiser valer só neste projeto: git config user.name "Seu Nome" e git config user.email "voce@exemplo.com".
Os 2 comandos deste passo, em ordem.
Fontes deste passoEsconder as fontes
Fonte: Pro Git: Contribuindo com um projeto (sem data na página; CC BY-NC-SA 3.0); Conventional Commits 1.0.0 (sem data na página; CC BY 3.0) · abertas em (reconferência semanal registrada)
Enviar a branch para o seu fork
O push leva o seu commit do computador para o seu fork no GitHub. É lá que o pull request vai buscá-lo.
git push -u origin corrige-link-quebrado
O que faz: Envia a branch para o origin (o seu fork) e liga a branch local à remota, para os próximos git push saberem para onde ir.
Erro comum: Você rodou só git push na primeira vez.
O Git responde: fatal: The current branch corrige-link-quebrado has no upstream branch.
Como sair: Use o comando completo com -u origin e o nome da branch, como acima.
Fontes deste passoEsconder as fontes
Fonte: GitHub Docs: Contributing to a project (sem data na página; CC BY 4.0 (conteúdo); MIT (código)) · abertas em (reconferência semanal registrada)
Passo 07Abrir o pull request
O pull request é o pedido para o projeto original aceitar a sua mudança. Este passo acontece no site do GitHub e não foi testado aqui.
- Abra a página do projeto original: aparece um aviso amarelo com o botão Compare & pull request. Clique nele.
- Confira os dois lados: o repositório base é o original e a branch de comparação é a sua, no seu fork.
- Escreva um título e explique o que mudou e por quê. Se a mudança resolve uma issue, escreva "Closes #número" (vale quando o pull request vai para a branch padrão).
- Se o projeto aceitar, deixe marcado "Allow edits from maintainers" e clique em Create pull request. Para pedir só uma opinião antes, crie como rascunho (draft).
Este passo acontece no site do GitHub e vem da documentação oficial; não foi testado aqui.
Fontes deste passoEsconder as fontes
Fonte: GitHub Docs: Creating a pull request from a fork (sem data na página; CC BY 4.0 (conteúdo); MIT (código)); GitHub Docs: Linking a pull request to an issue (sem data na página; CC BY 4.0 (conteúdo); MIT (código)) · abertas em (reconferência semanal registrada)
Responder à revisão
Quem mantém o projeto pode pedir ajustes. Faça-os na mesma branch: o pull request se atualiza sozinho a cada push.
git add README.md
O que faz: Marca o arquivo ajustado, como antes.
git commit -m "docs: ajusta o texto a pedido da revisão"
O que faz: Cria um novo commit com o ajuste. Prefira um commit novo a reescrever o anterior.
git push
O que faz: Envia o commit novo. Como a branch já está ligada (pelo -u), não precisa dizer para onde.
Erro comum: Você reescreveu um commit que já tinha enviado (por exemplo, com git commit --amend).
O Git responde: ! [rejected] corrige-link-quebrado -> corrige-link-quebrado (non-fast-forward)
Como sair: Evite reescrever commits já enviados: faça um commit novo. Se você reescreveu de propósito na sua branch de trabalho, envie com git push --force-with-lease, que substitui o histórico no fork só se ninguém mais mexeu nele.
Os 3 comandos deste passo, em ordem.
Fontes deste passoEsconder as fontes
Fonte: Open Source Guides: How to Contribute (sem data na página; CC BY 4.0); GitHub Docs: Reviewing proposed changes in a pull request (sem data na página; CC BY 4.0 (conteúdo); MIT (código)) · abertas em (reconferência semanal registrada)
Depois que aceitarem: atualizar o seu fork
O projeto original continua andando. Traga as novidades dele para o seu fork antes da próxima contribuição, e apague a branch que já cumpriu o papel.
git switch main
O que faz: Volta para a main do seu fork.
git fetch upstream
O que faz: Baixa as novidades do projeto original, sem mexer nos seus arquivos.
Erro comum: Você não registrou o upstream (passo de clonar).
O Git responde: fatal: 'upstream' does not appear to be a git repository
Como sair: Rode git remote add upstream <endereço do projeto original> e tente de novo.
git merge upstream/main
O que faz: Junta as novidades do original na sua main local. Isso só atualiza o seu computador.
Erro comum: Há alterações suas, ainda não guardadas, em arquivos que o merge também muda.
O Git responde: error: Your local changes to the following files would be overwritten by merge:
Como sair: Guarde a mudança num commit (ou use git stash) e rode o merge de novo.
git push origin main
O que faz: Envia a main atualizada para o seu fork no GitHub, para ele ficar igual ao original.
Erro comum: O fork recebeu commits que a sua main local não tem (por exemplo, pelo botão Sync fork do site).
O Git responde: ! [rejected] main -> main (fetch first)
Como sair: Rode git fetch origin e git merge origin/main, confira, e envie de novo.
git branch -d corrige-link-quebrado
O que faz: Apaga a branch local que já foi aceita. O -d recusa apagar o que ainda não foi juntado. Se o projeto aceitou com "squash and merge", o Git pode só avisar (warning) e apagar, porque a branch já foi enviada ao seu fork.
Erro comum: A branch tem commits que ainda não foram juntados na main nem enviados ao seu fork.
O Git responde: error: the branch 'corrige-link-quebrado' is not fully merged
Como sair: Confira no GitHub se o pull request foi aceito. Se foi e você quer descartar a branch, use git branch -D corrige-link-quebrado (D maiúsculo). Se não foi, não apague: envie com git push primeiro.
Os 5 comandos deste passo, em ordem.
Fontes deste passoEsconder as fontes
Fonte: GitHub Docs: Syncing a fork (sem data na página; CC BY 4.0 (conteúdo); MIT (código)); GitHub Docs: Contributing to a project (sem data na página; CC BY 4.0 (conteúdo); MIT (código)) · abertas em (reconferência semanal registrada)
Ver todos os comandos de uma vez
# Clonar o seu fork e ligar o projeto originalgit clone https://github.com/seu-usuario/projeto.gitcd projetogit remote add upstream https://github.com/dono-do-projeto/projeto.gitgit remote -v # Criar uma branch para a sua mudançagit switch -c corrige-link-quebrado # Fazer a mudança e conferir o que mudougit statusgit diffgit diff --check # Guardar a mudança em um commitgit add README.mdgit commit -m "docs: corrige o link quebrado do README" # Enviar a branch para o seu forkgit push -u origin corrige-link-quebrado # Responder à revisãogit add README.mdgit commit -m "docs: ajusta o texto a pedido da revisão"git push # Depois que aceitarem: atualizar o seu forkgit switch maingit fetch upstreamgit merge upstream/maingit push origin maingit branch -d corrige-link-quebradoOs erros que mais travam quem começa
Cada um foi reproduzido em um repositório de exemplo, com o Git 2.55. A primeira linha da resposta do Git é a que está na tabela.
| Comando | O Git responde | Como sair |
|---|---|---|
git clone https://github.com/seu-usuario/projeto.git | fatal: destination path 'projeto' already exists and is not an empty directory. | Entre na pasta que já existe (cd) ou apague-a, ou clone com outro nome de pasta no fim do comando. |
git remote add upstream https://github.com/dono-do-projeto/projeto.git | error: remote upstream already exists. | Rode git remote -v para ver o que está registrado. Para trocar o endereço, use git remote set-url upstream <endereço>. |
git remote -v | fatal: not a git repository (or any of the parent directories): .git | Entre na pasta do projeto com cd e rode de novo. |
git switch -c corrige-link-quebrado | fatal: a branch named 'corrige-link-quebrado' already exists | Troque de branch com git switch corrige-link-quebrado, ou escolha outro nome. |
git status | nothing to commit, working tree clean | Você esqueceu de salvar o arquivo no editor, ou editou outra cópia da pasta. |
git diff | (sem saída) | O git diff só mostra o que ainda não foi marcado. Depois do git add, use git diff --staged. |
git diff --check | README.md:3: trailing whitespace. | Apague os espaços do fim da linha indicada e salve de novo. |
git add README.md | fatal: pathspec 'README.txt' did not match any files | Confira o nome (e as letras maiúsculas) com git status ou ls, e rode de novo. |
git commit -m "docs: corrige o link quebrado do README" | Author identity unknown | Rode os dois comandos que o próprio Git mostra, sem o --global se quiser valer só neste projeto: git config user.name "Seu Nome" e git config user.email "voce@exemplo.com". |
git push -u origin corrige-link-quebrado | fatal: The current branch corrige-link-quebrado has no upstream branch. | Use o comando completo com -u origin e o nome da branch, como acima. |
git push | ! [rejected] corrige-link-quebrado -> corrige-link-quebrado (non-fast-forward) | Evite reescrever commits já enviados: faça um commit novo. Se você reescreveu de propósito na sua branch de trabalho, envie com git push --force-with-lease, que substitui o histórico no fork só se ninguém mais mexeu nele. |
git fetch upstream | fatal: 'upstream' does not appear to be a git repository | Rode git remote add upstream <endereço do projeto original> e tente de novo. |
git merge upstream/main | error: Your local changes to the following files would be overwritten by merge: | Guarde a mudança num commit (ou use git stash) e rode o merge de novo. |
git push origin main | ! [rejected] main -> main (fetch first) | Rode git fetch origin e git merge origin/main, confira, e envie de novo. |
git branch -d corrige-link-quebrado | error: the branch 'corrige-link-quebrado' is not fully merged | Confira no GitHub se o pull request foi aceito. Se foi e você quer descartar a branch, use git branch -D corrige-link-quebrado (D maiúsculo). Se não foi, não apague: envie com git push primeiro. |
Os passos que acontecem no site do GitHub (Fork e Compare & pull request) vêm da documentação do GitHub e não foram testados aqui. Mensagens de erro do Git podem variar um pouco entre versões e idiomas; as da tabela são as do Git 2.55 em inglês.
Gere os arquivos que todo projeto precisa
Formulário à esquerda, arquivo pronto à direita, tudo no navegador.
Um projeto aberto fica mais fácil de usar e de ajudar quando tem um README que explica o que ele faz, um CONTRIBUTING que diz como contribuir e mensagens de commit que contam o histórico. Os três geradores abaixo montam o texto em Markdown, mostram uma pré-visualização e deixam você copiar ou baixar o arquivo. Nada que você digita é enviado a servidor.
Guias para cada etapa
Cada guia tem a fonte oficial aberta em 11/10/2026, com link e licença, e um exemplo resolvido.
Para quem vai contribuir, os guias abaixo aprofundam cada etapa. Para quem mantém um projeto, há guias sobre versionamento, changelog, código de conduta e segurança. Sobre licenças de código aberto, este site não repete o assunto: veja o codigolivre.dev.
Para quem vai contribuir
- 01Achar um projetoCinco sinais de projeto vivo, rótulos para iniciantes e o que ler antes de começar.
- 02Fazer o forkO que é o fork, como criar, clonar e ligar o projeto original com o nome upstream.
- 03Atualizar o forkSincronize seu fork com o projeto original: botão, GitHub CLI ou git fetch e merge.
- 04Abrir uma boa issueO que escrever para o problema ser reproduzido em um minuto, com exemplo bom e ruim.
- 05Mensagem de commitOs quatro hábitos do Pro Git e quando usar um -m ou vários.
- 06Conventional CommitsAs 16 regras da especificação 1.0.0 resumidas, com tipos, escopo, ! e BREAKING CHANGE.
- 07Abrir o pull requestCompare & pull request, base e fork de origem, rascunho e como fechar uma issue pela descrição.
- 08Revisar códigoComentar, sugerir e enviar uma revisão no GitHub, com um roteiro de leitura e tom.
- 09Resolver conflito de mergeComo ler as marcas <<<<<<<, ======= e >>>>>>> e concluir o merge na linha de comando.
Para quem mantém um projeto
- 01Versionamento semânticoMAJOR, MINOR e PATCH: quando cada número sobe, pré-lançamentos e as regras que surpreendem.
- 02Manter um changelogOs seis tipos de mudança, a seção Unreleased e um CHANGELOG.md pequeno para copiar.
- 03Código de condutaO que um código de conduta deve dizer, onde guardar e como usar o Contributor Covenant.
- 04SECURITY.mdComo criar a política de segurança, ativar o relato privado e um modelo pequeno.
- 05Manter um projetoCinco ideias da Open Source Guides: documentar, dizer não, dividir, automatizar e descansar.
- 06Escrever um READMEAs perguntas que o README responde, uma ordem que funciona e um modelo mínimo.
- 07Escrever um CONTRIBUTINGO que incluir no CONTRIBUTING.md, onde o GitHub o mostra e como não exagerar nas regras.
De onde vêm os comandos e as regras
Abertas em 11/10/2026 com rotina de reconferência semanal automatizada. Nenhuma dessas páginas mostra data. O texto do site é nosso, em português.
Este site conta com uma rotina semanal automatizada que reabre as páginas oficiais de documentação (GitHub Docs, Git SCM, Conventional Commits, SemVer, Open Source Guides, Contributor Covenant e SPDX) e verifica se os comandos, termos e regras continuam vigentes. Se alguma página oficial sair do ar ou mudar seu texto, o site mantém a data anterior e o item entra em revisão manual antes de qualquer alteração de conteúdo.
- Contributing to a project (GitHub Docs)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0 (conteúdo); MIT (código)
O que lemos: O caminho fork, clone, branch, alterar, commit, push e pull request, com os comandos git clone, git branch, git checkout, git add, git commit e git push.
Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso. - Fork a repository (GitHub Docs)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0 (conteúdo); MIT (código)
O que lemos: O que é um fork ("propor mudanças sem afetar o repositório original"), o botão Fork, o comando gh repo fork, clonar o fork, git remote add upstream e git remote -v, e os avisos sobre repositórios privados.
Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso. - Syncing a fork (GitHub Docs)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0 (conteúdo); MIT (código)
O que lemos: O botão Sync fork, o comando gh repo sync e, na linha de comando, git fetch upstream, git checkout main e git merge upstream/main; avisa que isso só atualiza a cópia local e que é preciso enviar com push.
Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso. - Creating a pull request from a fork (GitHub Docs)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0 (conteúdo); MIT (código)
O que lemos: O botão Compare & pull request, "compare across forks", repositório base e fork de origem, "Allow edits from maintainers" e o pull request em rascunho.
Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso. - Linking a pull request to an issue (GitHub Docs)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0 (conteúdo); MIT (código)
O que lemos: As palavras que fecham uma issue (close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved), a sintaxe "Closes #10" e "Fixes dono/repo#100", e que só vale quando o pull request vai para a branch padrão.
Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso. - Finding ways to contribute to open source on GitHub (GitHub Docs)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0 (conteúdo); MIT (código)
O que lemos: Como achar projetos (tópicos em github.com/topics, Trending, Explore, rótulos good first issue e help wanted), conferir se há manutenção, abrir issue antes de trabalho grande e as contribuições que não são código.
Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso. - Pro Git, 3.1 Ramificação no Git: Branches em Poucas Palavras (git-scm.com)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY-NC-SA 3.0
O que lemos: Um branch é um ponteiro móvel para um commit; HEAD aponta para o branch em que você está; git branch cria sem trocar; git checkout -b cria e troca; desde o Git 2.23, git switch e git switch -c fazem o mesmo papel.
Como usamos: Só link e fatos (nomes de comandos). A licença proíbe uso comercial e exige a mesma licença nas adaptações; como este site pode exibir anúncios, nenhum trecho do livro é copiado, traduzido ou adaptado. - Pro Git, 5.2 Git Distribuído: Contribuindo com um Projeto (git-scm.com)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY-NC-SA 3.0
O que lemos: As diretrizes de commit: conferir espaços em branco com git diff --check, um commit por mudança lógica, resumo de cerca de 50 caracteres, linha em branco e explicação por volta de 72 colunas, verbo no imperativo.
Como usamos: Só link e fatos (git diff --check; limites de 50 e 72 caracteres, tratados aqui como regra prática). Nenhum trecho do livro é copiado ou adaptado, por causa da cláusula NC. - How to Contribute to Open Source (Open Source Guides)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0
O que lemos: Contribuir vai além de código; arquivos-chave (LICENSE, README, CONTRIBUTING, CODE_OF_CONDUCT); conferir licença, commits recentes e tom do projeto; quando abrir issue e quando abrir pull request; comunicação pública e objetiva; o que fazer depois de enviar (esperar cerca de uma semana antes de cobrar, responder a pedidos de mudança, pedir retorno se recusado).
Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso.
Encontrou um comando que não bate com o Git do seu computador ou uma fonte que mudou? Escreva pela página de contato.
Perguntas frequentes
Quais são os passos do primeiro pull request?
Achar um projeto e uma tarefa pequena, fazer o fork, clonar o fork e registrar o original como upstream, criar uma branch, fazer a mudança, guardá-la em um commit, enviar a branch com git push e abrir o pull request no GitHub. Depois vêm a revisão e a atualização do fork.
Preciso saber usar o terminal para contribuir?
O terminal é o caminho que este passo a passo ensina, com poucos comandos: clone, branch, add, commit e push, cada um com o que faz e o erro mais comum. A documentação do GitHub também descreve o GitHub CLI e o GitHub Desktop para criar o fork e clonar, mas aqui testamos só os comandos de git.
Os comandos desta página foram testados?
Os comandos de terminal foram executados em um repositório local de exemplo, com um repositório original e um fork simulado, no Git 2.55, e cada erro comum foi reproduzido. Os passos que acontecem no site do GitHub, como o botão Fork e o Compare & pull request, vêm da documentação do GitHub e não foram testados aqui.
O que é upstream e o que é origin?
O origin é o endereço do seu fork, de onde você clonou. O upstream é o apelido que você dá ao repositório original ao registrá-lo com git remote add. Com os dois, você envia para o origin e busca novidades do upstream.
Meus dados ficam salvos em algum servidor?
Não. O seu usuário, o projeto e o nome da branch que você digita só reescrevem os comandos na tela e ficam guardados no armazenamento local do seu navegador. Nenhum campo é enviado a servidor.