> 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-10/recebendo-revisoes-em-um-pull-request-no-github/exemplo-pratico/lidando-com-o-feedback.md).

# Lidando com o Feedback

Na seção anterior, solicitamos a revisão do PR para a conta da **camilamaia**. Agora, vamos entender como lidar com o feedback recebido e aplicar as sugestões na prática.

A revisão da conta **camilamaia** foi concluída. Podemos verificar isso tanto na página [Página de Notificações (Notifications)](/github-essentials/dia-5/explorando-a-interface-do-github/pagina-de-notificacoes-notifications.md), clicando no notificação nova.

<figure><img src="/files/UQND1dx1yAiy2YzkJExG" alt=""><figcaption></figcaption></figure>

Ou, acessando diretamente o Histórico de Ações da [Broken mention](broken://pages/XHMUVKgh3HutmlDmDFKr) do PR.

<figure><img src="/files/WRMGTBKFHVttPdkHCG24" alt=""><figcaption></figcaption></figure>

O resultado da revisão foi: `❌ Solicitação de Alterações` . Além disso, há um comentário geral sobre o PR que diz:

> O PR está ótimo! Amei o gif do pinguim 🐧 Deixei apenas uma sugestão de alteração.

E um comentário contendo a sugestão que diz:

> Muitas ferramentas de programação processam arquivos linha por linha e esperam que cada uma termine com uma quebra de linha (`\n`). Quando isso não ocorre, a última linha pode ser interpretada incorretamente, causando erros ou comportamentos inesperados.
>
> Isso acontece porque muitos sistemas operacionais seguem o padrão Unix, um conjunto de regras e convenções amplamente adotado na computação. O Unix foi criado na década de 1970 e influenciou sistemas como Linux e macOS. Uma dessas convenções é que arquivos de texto devem terminar com uma quebra de linha para garantir compatibilidade com ferramentas que leem arquivos sequencialmente.
>
> Além disso, essa prática é recomendada por diversos editores de código e linters (ferramentas que analisam o código para garantir boas práticas).
>
> Por isso, sugiro adicionar uma linha vazia no final deste arquivo.
>
> Aqui estão algumas referências que explicam isso melhor:
>
> * [Por que inserir uma linha em branco no final do código?](https://pt.stackoverflow.com/questions/272449/por-que-inserir-uma-linha-em-branco-no-final-do-c%c3%b3digo)
> * [Por que arquivos devem terminar com uma quebra de linha?](https://jlozovei.dev/pt-br/blog/why-you-should-put-a-newline-at-the-end-of-your-code/)
>
> Se precisar de mais explicações, é só avisar!

**Sugestão de Alteração**: A mudança sugerida adiciona uma linha em branco ao final do arquivo README.md. Isso é uma boa prática recomendada por sistemas Unix e ferramentas de análise de código para evitar problemas de compatibilidade.\
A revisora explicou detalhadamente a importância dessa alteração e forneceu links para referências.

**Status do PR**: Uma solicitação de alteração pendente. Não há conflitos com a branch base, então o merge poderá ser feito automaticamente.

Vamos começar reagindo ao comentário positivo recebido.

<div><figure><img src="/files/lJdmYI0Z5AUCDuiyqrfC" alt=""><figcaption></figcaption></figure> <figure><img src="/files/JAkbgSqVVrvV9b6dPFiv" alt=""><figcaption></figcaption></figure></div>

Agora, vamos analisar a sugestão oferecida.

* **Entendemos a sugestão?** Sim, a motivação e o que precisa ser feito estão bem explicados.
* **Concordamos com a sugestão?** Sim, parece ser um padrão adotado e que faz sentido.

Sendo assim, vamos aceitar a sugestão. Para isso, clicamos no botão **Commit suggestion** abaixo da sugestão.

<figure><img src="/files/PZZIbrg6Nz4djMjrB1kX" alt=""><figcaption></figcaption></figure>

Na caixa de diálogo, preenchemos a mensagem principal com:&#x20;

```
Adiciona linha vazia ao final do arquivo README.md
```

E a mensagem adicional com:

```
Muitas ferramentas de programação processam arquivos linha por linha e esperam que cada uma termine com uma quebra de linha (\n). Quando isso não ocorre, a última linha pode ser interpretada incorretamente, causando erros ou comportamentos inesperados.
Isso acontece porque muitos sistemas operacionais seguem o padrão Unix, um conjunto de regras e convenções amplamente adotado na computação. O Unix foi criado na década de 1970 e influenciou sistemas como Linux e macOS. Uma dessas convenções é que arquivos de texto devem terminar com uma quebra de linha para garantir compatibilidade com ferramentas que leem arquivos sequencialmente.

Além disso, essa prática é recomendada por diversos editores de código e linters (ferramentas que analisam o código para garantir boas práticas).

Referências:
- https://pt.stackoverflow.com/questions/272449/por-que-inserir-uma-linha-em-branco-no-final-do-c%C3%B3digo
- https://jlozovei.dev/pt-br/blog/why-you-should-put-a-newline-at-the-end-of-your-code/
```

Clicamos em "Commit changes". Isso cria um commit e já resolve a conversa automaticamente.

<figure><img src="/files/1VQDCc5D4I9sQuBAayWW" alt=""><figcaption></figcaption></figure>

A página é atualizada e exibe um painel no topo com a mensagem "*Suggestion successfully applied*", indicando que a sugestão foi aplicada com sucesso.

<figure><img src="/files/7wBFlLfr2jCgGRiN71vM" alt=""><figcaption></figcaption></figure>

Podemos ver também que o novo commit já consta na seção de Histórico de Ações.

<figure><img src="/files/7cUxEnZr0xiDqXHD4chy" alt=""><figcaption></figcaption></figure>

E que agora, na [Broken mention](broken://pages/yMaK5mxLS3CM3TRF1L02), o novo commit aparece.

<div><figure><img src="/files/EuivtXbRLbi3vewgxpTo" alt=""><figcaption></figcaption></figure> <figure><img src="/files/BKnCh17HfCxrswl4QYmU" alt=""><figcaption></figcaption></figure></div>

Na [Aba Files Changed](/github-essentials/dia-10/pagina-de-um-pull-request-no-github/aba-files-changed.md), onde o comentário com a sugestão estava presente, agora há um painel com a mensagem "***aprendizCumbucaDev** marked this conversation as resolved*", indicando que a conversa foi marcada como resolvida pela conta **aprendizCumbucaDev** (feito automaticamente ao aceitar a sugestão).

<figure><img src="/files/beGymDUCKvAJLg29sAVd" alt=""><figcaption></figcaption></figure>

Por fim, re-solicitamos a revisão da conta **camilamaia**.

<figure><img src="/files/3JURkPlBww8GcRHRv5lQ" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/KKEjZI0ntIorIcd4I1Cx" alt=""><figcaption></figcaption></figure>

E, **camilamaia** aprova o PR 🎉

<figure><img src="/files/sDjiWeSjVjAAcZDVubnO" alt=""><figcaption></figcaption></figure>

***

Agora, a revisão está completa! Nas próximas seções, vamos aprender como mesclar um PR ao branch principal.


---

# 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-10/recebendo-revisoes-em-um-pull-request-no-github/exemplo-pratico/lidando-com-o-feedback.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.