> For the complete documentation index, see [llms.txt](https://cumbucadev.gitbook.io/github-essentials/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cumbucadev.gitbook.io/github-essentials/dia-11/forks-e-pull-requests/preparando-o-fork-para-a-proxima-contribuicao.md).

# Preparando o Fork para a próxima contribuição

Depois que um Pull Request é mesclado, o trabalho no projeto não termina. Se você pretende continuar contribuindo, é importante preparar o seu fork antes de começar uma nova alteração.

Enquanto você trabalha em um fork, o repositório original continua evoluindo. Outras pessoas podem estar corrigindo bugs, adicionando funcionalidades, reorganizando arquivos ou melhorando a documentação. Mesmo quando um Pull Request seu é mesclado, **essas mudanças não voltam automaticamente para o seu fork**. Se o seu fork ficar desatualizado em relação ao upstream, iniciar uma nova contribuição a partir dele pode gerar conflitos desnecessários e retrabalho.

Por isso, antes de começar uma nova mudança, o primeiro passo deve ser garantir que o fork está sincronizado.

## O que significa “preparar o fork”?

Preparar o fork não é apenas atualizar arquivos. É garantir que a **base de trabalho esteja correta** antes de criar um novo branch ou iniciar uma nova funcionalidade.

Esse preparo envolve dois passos conceituais importantes:

1. Atualizar o `main` do seu fork com o `main` do repositório original (*upstream*).
2. Criar um novo branch de trabalho a partir desse `main` já atualizado.

O fluxo esperado é sempre:

```
upstream/main → main do fork → novo branch de trabalho
```

Seguir essa ordem evita que você:

* trabalhe sobre código desatualizado;
* carregue conflitos antigos para uma nova contribuição;
* misture mudanças de Pull Requests anteriores com trabalho novo.

## Quando preparar o fork novamente?

Você deve preparar o fork para a próxima contribuição sempre que:

* começar a trabalhar em uma nova issue;
* um Pull Request seu tiver sido mesclado ou fechado;
* você ficou algum tempo sem contribuir no projeto;

Esses sinais indicam que a base do seu fork pode não estar mais alinhada com o projeto original.

## Passo a Passo

### Atualizando o `main` do fork remoto com o upstream

Antes de criar um novo branch, comece garantindo que o `main` do seu fork está sincronizado com o repositório original.

#### Verificando se o fork está desatualizado

Na página principal do seu fork no GitHub, observe a mensagem exibida no topo do repositório. Quando o fork está atrás do upstream, o GitHub mostra algo como:

> 🇬🇧 This branch is X commits behind \<upstream>:main
>
> 🇧🇷 Este branch está X commits atrás de :main

Esse aviso indica que existem commits no repositório original que ainda não estão no seu fork.

#### Atualizando o `main` pela interface do GitHub

Quando não há conflitos, a forma mais simples de atualizar o fork é pela interface gráfica.

1. Na página do seu fork, clique em **Sync fork**.
2. Em seguida, clique em **Update branch**.
3. Confirme a ação.

Após a atualização, a mensagem muda para:

> 🇬🇧 This branch is up to date with \<upstream>:main
>
> 🇧🇷 Este branch está atualizado com \<upstream>:main

Isso indica que o `main` do seu fork agora reflete exatamente o estado atual do repositório original.

### Criando um novo branch para a próxima contribuição

Com o `main` do fork remoto atualizado, o próximo passo é atualizar o main do fork local e criar um novo branch de trabalho. Evite reutilizar branches antigos, pois eles podem conter histórico e conflitos de contribuições anteriores.

No terminal, execute:

```sh
git switch main
git pull origin main
git switch -c novo-branch
```

Esse novo branch agora está baseado na versão mais recente do projeto.

A partir daqui, você pode:

* fazer suas alterações;
* criar commits;
* abrir um novo Pull Request com segurança.

## Quando o fork não é atualizado antes de continuar

Ignorar essa etapa pode causar problemas comuns, como:

* conflitos logo no início do trabalho;
* Pull Requests difíceis de revisar;
* necessidade de resolver conflitos que poderiam ter sido evitados.

Preparar o fork antes de cada nova contribuição garante:

* uma base limpa e atualizada;
* menos conflitos;
* um histórico mais organizado;
* revisões mais rápidas.

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cumbucadev.gitbook.io/github-essentials/dia-11/forks-e-pull-requests/preparando-o-fork-para-a-proxima-contribuicao.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.