Capítulo 3 Reprodutibilidade: Git, R Markdown e Workflow

Objetivos do capítulo

Entender por que reprodutibilidade importa na pesquisa científica
Usar Git e GitHub para controle de versão
Produzir relatórios reproduzíveis com R Markdown
Organizar o workflow de um projeto de pesquisa
Conhecer o uso de agentes de IA no fluxo de trabalho acadêmico

3.1 Por que reprodutibilidade?

Em um projeto de pesquisa, a menor parte do tempo é gasta fazendo a análise dos dados propriamente dita. A maior parte é investida na preparação dos dados e na comunicação dos resultados. Como Przeworski afirmou: “This is the job: you rewrite, and you rewrite, and you rewrite.”

A reprodutibilidade é a capacidade de outra pessoa (ou você mesmo, meses depois) refazer toda a análise a partir dos dados e do código original, chegando aos mesmos resultados. Isso é fundamental por várias razões:

Credibilidade científica: resultados reproduzíveis são mais confiáveis. A crise de replicação em diversas áreas (psicologia, economia, medicina) mostrou que muitos achados publicados não se sustentam quando replicados.
Transparência: o leitor (e os pareceristas) podem verificar cada passo da análise. Isso reduz erros e aumenta a confiança nos resultados.
Eficiência pessoal: quando seu projeto está bem organizado e documentado, você consegue retomar o trabalho rapidamente, mesmo após semanas sem mexer nele.
Colaboração: projetos reproduzíveis facilitam o trabalho em equipe, pois qualquer coautor pode entender e executar a análise.

Para garantir reprodutibilidade, três ferramentas são essenciais: Git (controle de versão), R Markdown (integração de código e texto) e um workflow organizado (estrutura de pastas e scripts). Vamos abordar cada uma.

3.2 Controle de versão com Git e GitHub

3.2.1 O que é Git e GitHub?

Git é um sistema de controle de versão que permite rastrear mudanças nos seus arquivos ao longo do tempo. Pense nele como um “histórico de alterações” muito poderoso para seus projetos.

GitHub é uma plataforma online que hospeda repositórios Git, permitindo colaboração, backup na nuvem e compartilhamento de código.

Para cientistas sociais, usar Git e GitHub é importante por diversas razões:

Reprodutibilidade: qualquer pessoa pode acessar seu código e dados e reproduzir suas análises.
Backup: seu trabalho fica salvo na nuvem.
Colaboração: permite trabalhar em equipe de forma organizada.
Portfólio: seus projetos ficam visíveis para a comunidade acadêmica e profissional.

3.2.2 Criando uma conta no GitHub

Acesse https://github.com e crie uma conta gratuita. Use seu e-mail institucional se possível, pois isso dá acesso a benefícios educacionais (GitHub Education).

3.2.3 Instalando o Git

Antes de conectar o RStudio ao GitHub, é preciso ter o Git instalado no computador.

Windows: Baixe em https://git-scm.com/download/win e instale com as opções padrão.
Mac: Abra o Terminal e digite git --version. Se não estiver instalado, o sistema oferecerá a instalação automática (via Xcode Command Line Tools). Alternativamente, baixe em https://git-scm.com/download/mac.
Linux: Use o gerenciador de pacotes da sua distribuição. Por exemplo, no Ubuntu: sudo apt install git.

3.2.4 Configuração inicial do Git

Após instalar o Git, abra o Terminal (ou o terminal do RStudio, na aba “Terminal”) e configure seu nome e e-mail:

git config --global user.name "Seu Nome"
git config --global user.email "seu.email@exemplo.com"

Use o mesmo e-mail que cadastrou no GitHub.

3.2.5 Conectando o RStudio ao GitHub

3.2.5.1 Passo 1: Instalar o pacote `usethis`

No console do RStudio, execute:

install.packages("usethis")

3.2.5.2 Passo 2: Criar um token de acesso pessoal (PAT)

O GitHub não aceita mais senha para autenticação via Git. É necessário criar um token de acesso pessoal. No console do RStudio, execute:

usethis::create_github_token()

Isso abrirá o navegador na página de criação de token do GitHub. Dê um nome descritivo ao token (por exemplo, “RStudio”) e clique em “Generate token”. Copie o token gerado — ele não será mostrado novamente.

3.2.5.3 Passo 3: Armazenar o token no RStudio

No console do RStudio, execute:

install.packages("gitcreds")
gitcreds::gitcreds_set()

Quando solicitado, cole o token que você copiou no passo anterior.

3.2.5.4 Passo 4: Verificar a configuração

Para confirmar que tudo está funcionando, execute:

usethis::git_sitrep()

Você deve ver informações sobre seu nome, e-mail e o token de acesso configurado.

3.2.6 Criando um projeto com controle de versão

3.2.6.1 Opção A: Criar um novo repositório no GitHub e clonar

No GitHub, clique em “New repository”.
Dê um nome ao repositório (por exemplo, “meu-projeto-estatistica”).
Marque “Add a README file”.
Clique em “Create repository”.
Copie a URL do repositório (botão verde “Code”).
No RStudio, vá em File > New Project > Version Control > Git.
Cole a URL do repositório e escolha a pasta onde o projeto será salvo.
Clique em “Create Project”.

3.2.6.2 Opção B: Transformar um projeto existente do RStudio em repositório Git

No RStudio, abra o projeto existente.
No console, execute:

usethis::use_git()

Confirme a criação do repositório Git. O RStudio reiniciará.
Depois, para conectar ao GitHub:

usethis::use_github()

Isso criará automaticamente um repositório no GitHub e fará a conexão.

3.2.7 Fluxo básico de trabalho com Git no RStudio

Após configurar o projeto, a aba Git aparecerá no painel superior direito do RStudio. O fluxo básico de trabalho é:

Modificar arquivos: edite seus scripts normalmente.
Stage (preparar): na aba Git, marque a caixa ao lado dos arquivos que deseja salvar.
Commit (registrar): clique em “Commit”, escreva uma mensagem descrevendo as alterações e clique em “Commit”.
Push (enviar): clique na seta verde para cima (“Push”) para enviar as alterações para o GitHub.
Pull (receber): clique na seta azul para baixo (“Pull”) para receber alterações do GitHub (útil quando trabalhando em equipe).

3.2.8 Boas práticas com Git

Faça commits frequentes com mensagens claras (por exemplo: “Adiciona análise descritiva do PIB municipal”).
Sempre faça Pull antes de começar a trabalhar, para garantir que está com a versão mais recente.
Não coloque dados sensíveis ou muito grandes no GitHub. Use um arquivo .gitignore para excluí-los.

3.2.9 Branches: acabando com `tese_final_final_v7.docx`

Todo mundo que já escreveu um trabalho acadêmico conhece o problema: o arquivo começa como tese.docx, vira tese_v2.docx, depois tese_final.docx, tese_final_corrigida.docx, tese_final_final_v7_agora_vai.docx. Cada versão é uma cópia do arquivo inteiro, ninguém sabe mais qual é a versão correta, e desfazer uma mudança exige comparar arquivos manualmente.

O Git resolve esse problema com branches (ramificações). Uma branch é uma linha independente de desenvolvimento que permite experimentar mudanças sem afetar o trabalho principal. Em vez de criar cópias do arquivo, você cria uma branch, faz as mudanças nela e, se gostar do resultado, incorpora as alterações de volta à versão principal.

3.2.9.1 Como funciona?

Quando você cria um repositório Git, ele começa com uma branch padrão chamada main. Essa é a “versão oficial” do projeto. A partir dela, você pode criar novas branches para trabalhar em tarefas específicas:

main:                 ●───●───●───●───●───●
                           \             /
nova-analise:               ●───●───●──●

No diagrama acima, a branch nova-analise diverge da main, recebe alguns commits com as mudanças, e depois é mesclada (merged) de volta à main. Durante todo esse processo, a main permanece intacta — se a nova análise não funcionar, basta deletar a branch e nada se perde.

3.2.9.2 Quando usar branches?

Branches são úteis sempre que você quer experimentar algo sem arriscar o que já funciona:

Testar uma especificação diferente do modelo: crie uma branch modelo-alternativo, rode a análise e compare com a original.
Incorporar comentários de um parecerista: crie uma branch revisao-r1, faça todas as alterações pedidas e, ao final, mescle de volta à main.
Escrever uma nova seção do paper: trabalhe em uma branch secao-teoria até estar satisfeito, sem interferir no texto que já está pronto.
Experimentar uma visualização diferente: crie uma branch graficos-v2 para testar novas figuras.

3.2.9.3 Comandos básicos de branches

No terminal (ou na aba Terminal do RStudio):

# Ver em qual branch você está
git branch

# Criar uma nova branch e mudar para ela
git checkout -b revisao-r1

# Mudar para outra branch existente
git checkout main

# Mesclar mudanças de uma branch na branch atual
# (estando na main, traz as mudanças de revisao-r1)
git merge revisao-r1

# Deletar uma branch após mesclá-la
git branch -d revisao-r1

No RStudio, você também pode gerenciar branches pela interface gráfica: na aba Git, há um menu dropdown que mostra a branch atual e permite criar ou trocar de branch.

3.2.9.4 Boas práticas com branches

Dê nomes descritivos: revisao-r1, analise-robustez, secao-metodo são melhores do que teste ou branch2.
Mantenha branches focadas: cada branch deve ter um propósito claro. Não misture a revisão do texto com mudanças na análise de dados.
Mescle frequentemente: não deixe uma branch divergir demais da main. Quanto mais tempo separada, mais difícil será a mesclagem.
Delete branches mescladas: após mesclar, delete a branch para manter o repositório organizado.

Com branches, o fluxo de trabalho acadêmico fica assim: a main sempre contém a versão estável do projeto, e cada experimento ou revisão acontece em sua própria branch. Não há mais tese_final_final_v7.docx — há uma única versão principal com todo o histórico de mudanças preservado e rastreável.

3.2.10 Worktrees: trabalhando em várias versões ao mesmo tempo

Branches resolvem o problema de criar versões paralelas, mas têm uma limitação prática: quando você troca de branch (git checkout outra-branch), todos os arquivos do projeto mudam. Se você estiver no meio de uma análise na branch revisao-r1 e precisar consultar algo na main, precisa salvar tudo, trocar de branch, olhar o que precisa e voltar. Isso é inconveniente e pode causar erros.

O Git oferece uma solução para isso: worktrees (árvores de trabalho). Uma worktree é uma segunda cópia do repositório, em uma pasta separada, vinculada a uma branch diferente. Isso permite ter duas (ou mais) versões do projeto abertas ao mesmo tempo, cada uma em sua própria pasta.

3.2.10.1 Como funciona?

Normalmente, um repositório Git tem apenas uma “árvore de trabalho” — a pasta onde seus arquivos estão. Com git worktree, você cria pastas adicionais, cada uma ligada a uma branch:

meu-projeto/                  ← worktree principal (branch main)
meu-projeto-revisao/          ← worktree adicional (branch revisao-r1)

Ambas as pastas compartilham o mesmo histórico Git (commits, branches etc.), mas mostram versões diferentes dos arquivos. Você pode abrir cada uma em uma janela separada do RStudio e trabalhar nas duas ao mesmo tempo.

3.2.10.2 Quando usar worktrees?

Worktrees são especialmente úteis em três situações:

Comparar versões lado a lado: abrir a versão atual e a anterior em duas janelas do RStudio para comparar resultados, tabelas ou gráficos.
Atender uma demanda urgente sem perder o contexto: se você está no meio de uma revisão e o orientador pede uma mudança urgente na versão principal, pode criar uma worktree da main, fazer a correção e voltar ao seu trabalho sem ter perdido nada.
Rodar análises longas em paralelo: enquanto uma especificação do modelo roda em uma worktree, você pode continuar editando o texto em outra.

3.2.10.3 Comandos básicos de worktrees

# Criar uma worktree para uma branch existente
git worktree add ../meu-projeto-revisao revisao-r1

# Criar uma worktree com uma nova branch
git worktree add -b experimento ../meu-projeto-experimento

# Listar worktrees ativas
git worktree list

# Remover uma worktree (após terminar o trabalho)
git worktree remove ../meu-projeto-revisao

Note que a worktree é criada fora da pasta do projeto (com ../), para evitar confusão. Cada worktree é uma pasta normal que pode ser aberta no RStudio como um projeto separado.

3.2.10.4 Worktrees vs. clonar o repositório

Uma alternativa simples seria clonar o repositório em outra pasta. A diferença é que worktrees compartilham o histórico Git: um commit feito em qualquer worktree é imediatamente visível nas outras. Com clones separados, você precisa fazer push e pull entre eles, o que é mais trabalhoso e propenso a conflitos.

3.3 R Markdown

3.3.1 O que é R Markdown?

R Markdown é um formato de documento que permite integrar código R, resultados e texto formatado em um único arquivo. Isso elimina a inconsistência entre a análise e o relatório: quando os dados mudam, basta recompilar o documento e todos os resultados são atualizados automaticamente.

Um arquivo R Markdown tem extensão .Rmd e pode ser convertido (renderizado) em diversos formatos: HTML, PDF, Word, apresentações e até livros (como este que você está lendo, feito com bookdown).

3.3.2 Estrutura de um documento `.Rmd`

Todo arquivo .Rmd tem três componentes:

1. Cabeçalho YAML (entre ---): define metadados como título, autor, data e formato de saída.

---
title: "Minha Análise"
author: "Seu Nome"
date: "2025-03-05"
output: html_document
---

2. Texto formatado com Markdown: o corpo do documento usa a sintaxe Markdown para formatação.

Sintaxe	Resultado
`negrito`	negrito
`itálico`	itálico
`# Título`	Título nível 1
`## Subtítulo`	Título nível 2
`- item`	Lista com marcadores
`1. item`	Lista numerada
`[texto](url)`	Link

3. Chunks de código R: blocos de código que são executados quando o documento é renderizado.

Um chunk é delimitado por três crases e {r}:

```{r nome-do-chunk}
# código R aqui
mean(c(1, 2, 3, 4, 5))
```

3.3.2.1 Opções de chunk

Cada chunk pode ter opções que controlam o comportamento:

echo = TRUE/FALSE: mostrar ou esconder o código no documento final.
eval = TRUE/FALSE: executar ou não o código.
message = FALSE: suprimir mensagens.
warning = FALSE: suprimir avisos.
fig.width, fig.height: dimensões de figuras.
cache = TRUE: salvar resultados em cache (útil para código demorado).

Exemplo:

```{r grafico-pib, echo=FALSE, fig.width=8, fig.height=5}
library(ggplot2)
ggplot(data, aes(x = pib, y = idh)) + geom_point()
```

3.3.3 Gerando relatórios

Para renderizar o documento, clique no botão Knit no RStudio ou execute no console:

rmarkdown::render("meu_relatorio.Rmd")

Os formatos mais comuns de saída são:

html_document: página web (mais flexível, recomendado para começar).
pdf_document: PDF (requer LaTeX instalado — veja abaixo).
word_document: arquivo Word.

Para gerar PDFs, é necessário ter uma distribuição LaTeX instalada. A forma mais simples é usar o pacote tinytex, que instala uma versão mínima do LaTeX diretamente pelo R:

install.packages("tinytex")
tinytex::install_tinytex()

A instalação pode levar alguns minutos. Após concluída, o botão Knit com saída pdf_document funcionará normalmente. O tinytex baixa automaticamente pacotes LaTeX adicionais conforme necessário, então você não precisa se preocupar em gerenciar a instalação manualmente.

3.3.4 Fórmulas matemáticas com LaTeX

Dentro do R Markdown, é possível incluir fórmulas matemáticas usando a sintaxe LaTeX. Para fórmulas inline, use $...$ . Para fórmulas em destaque, use $$...$$.

Exemplos:

Inline: $\bar{x} = \frac{1}{n}\sum_{i=1}^{n} x_i$ gera $\bar{x} = \frac{1}{n}\sum_{i=1}^{n} x_i$
Em destaque:

$$\sigma^2 = \frac{1}{n}\sum_{i=1}^{n}(x_i - \bar{x})^2$$

\[\sigma^2 = \frac{1}{n}\sum_{i=1}^{n}(x_i - \bar{x})^2\]

Alguns comandos LaTeX úteis:

Comando	Resultado
`\frac{a}{b}`	$\frac{a}{b}$
`\sqrt{x}`	$\sqrt{x}$
`\sum_{i=1}^{n}`	$\sum_{i=1}^{n}$
`\bar{x}`	$\bar{x}$
`\hat{\beta}`	$\hat{\beta}$
`\alpha, \beta, \mu, \sigma`	$\alpha, \beta, \mu, \sigma$
`\leq, \geq, \neq`	$\leq, \geq, \neq$

3.4 Organizando o workflow de um projeto

3.4.1 Por que organizar?

Um projeto de pesquisa envolve dados, scripts de limpeza, scripts de análise, figuras, tabelas e o texto do paper. Sem uma organização clara, é muito fácil perder o controle de qual script gerou qual resultado, ou qual versão dos dados foi usada na análise final. Um bom workflow garante que qualquer pessoa — incluindo você no futuro — consiga reproduzir toda a análise.

3.4.2 Estrutura de pastas

A convenção recomendada é separar os arquivos por função:

meu-projeto/
├── data/
│   ├── raw/            # dados originais, NUNCA modificados
│   └── processed/      # dados limpos, prontos para análise
├── scripts/           # código R (01_clean.R, 02_analysis.R etc.)
├── outputs/           # tabelas, figuras, modelos exportados
├── paper/             # texto em RMarkdown
├── references/        # artigos e textos usados como referência
├── sandbox/           # scripts exploratórios e experimentos
├── README.md          # instruções de reprodução
└── .gitignore         # arquivos que o Git deve ignorar

Regra de ouro: os dados originais na pasta data/raw/ nunca devem ser modificados. Toda limpeza e transformação é feita por script, e os resultados vão para data/processed/. Isso garante que sempre é possível refazer a limpeza do zero.

3.4.3 Pipeline de análise

Quando o projeto está maduro, a ordem dos scripts deve refletir o fluxo lógico da análise:

01_clean.R — importa os dados brutos e gera os dados limpos.
02_analysis.R — roda os modelos estatísticos.
03_figures.R — gera figuras e tabelas.
04_paper.Rmd — integra resultados e texto no documento final.

Na prática, porém, é difícil saber de antemão como será essa estrutura. No início de um projeto, você ainda está explorando os dados e não sabe ao certo quais análises fará. Não há problema em começar com um único script. Uma estratégia útil é criar uma pasta sandbox/ no projeto — um espaço para experimentar e explorar livremente, sem se preocupar com organização. Você pode colocar ali um script exploratório onde testa limpezas, visualizações e modelos à medida que entende os dados. Quando tiver uma visão mais clara do projeto, organiza tudo nas pastas certas, quebra o script em partes numeradas e segue a estrutura do pipeline. A pasta sandbox/ fica como registro do processo exploratório e pode ser revisitada se uma análise futura exigir novas explorações.

Duas abordagens para executar o pipeline:

Pipeline pragmático: rodar cada script manualmente, na ordem. Simples e funcional para projetos menores.
Pipeline automatizado: usar pacotes como targets ou ferramentas como make para documentar as dependências entre scripts e executar tudo automaticamente. Mais robusto para projetos grandes.

3.4.4 Replication package

Quando seu paper estiver pronto para submissão, monte um replication package — o conjunto de materiais necessários para reproduzir toda a análise. Um bom replication package contém:

README.md: título do paper, instruções de reprodução (versão do R, pacotes necessários, ordem dos scripts) e descrição das bases de dados (com links para fontes públicas quando possível).
Dados: os dados utilizados (ou instruções de acesso, quando não podem ser compartilhados).
Scripts: todos os scripts de análise.
Paper: o arquivo do texto (.Rmd + PDF).

Uma boa prática é incluir sessionInfo() no final de cada script, para registrar as versões exatas de R e dos pacotes utilizados.

Repositórios de dados como o Harvard Dataverse são o padrão em ciência política para depositar replication packages. Eles geram um DOI (identificador permanente) para o seu material, garantindo preservação e facilitando citação. No Brasil, existe o Scielo Data como alternativa.

3.4.5 Escrevendo com RMarkdown e referências bibliográficas

A principal vantagem de escrever o paper em RMarkdown é que os resultados da análise estão diretamente integrados ao texto. Se você corrige um erro nos dados ou muda uma especificação do modelo, basta recompilar o documento — todas as tabelas e figuras são atualizadas automaticamente. Isso elimina o problema clássico de inconsistências entre o que está no script e o que está no paper.

Para gerenciar referências bibliográficas, exporte sua biblioteca do Zotero (ou outro gerenciador) em formato .bib e cite no texto com [@autor_ano]. O R Markdown gera a bibliografia formatada automaticamente.

3.5 Agentes de IA no fluxo de trabalho acadêmico

3.5.1 O que são agentes de IA?

Modelos de linguagem (LLMs), como o ChatGPT e o Claude, são sistemas de inteligência artificial treinados para compreender e gerar texto. Quando esses modelos são equipados com ferramentas — como a capacidade de ler e editar arquivos, executar código, fazer buscas na web — eles se tornam agentes de IA: sistemas capazes de executar tarefas complexas de forma autônoma ou semi-autônoma.

Para pesquisadores, agentes de IA são particularmente úteis porque podem auxiliar em diversas etapas do trabalho acadêmico:

Análise de dados: escrever e executar código em R ou Python, gerar tabelas e figuras.
Escrita e revisão: redigir seções de texto, revisar gramática, verificar consistência de argumentos.
Revisão de literatura: buscar e sintetizar artigos relevantes.
Depuração de código: identificar e corrigir erros em scripts.

3.5.2 Como agentes podem ajudar na pesquisa

Um exemplo concreto: ferramentas como o Claude Code funcionam como um ambiente de trabalho para pesquisa acadêmica. Nesse tipo de sistema, agentes especializados podem ser configurados para tarefas específicas:

Análise de dados em R: um agente que conhece tidyverse, fixest, modelsummary e pode escrever, executar e revisar scripts de análise completos.
Revisão de paper: um agente que simula o papel de um parecerista (referee), avaliando contribuição, execução e exposição de um manuscrito.
Compilação de documentos: um agente que renderiza R Markdown e faz o deploy do documento.

O fluxo geral de trabalho com agentes segue um padrão:

Planejar: descrever a tarefa que se deseja realizar.
Delegar: o agente executa a tarefa (escreve código, edita texto, gera figuras).
Revisar: o pesquisador verifica os resultados e fornece feedback.
Iterar: o agente refina o trabalho com base no feedback.

3.5.3 Custos e acesso

Usar agentes de IA tem um custo. Os modelos consomem tokens — unidades de texto processadas — tanto na entrada (o que você envia) quanto na saída (o que o modelo gera). Quanto mais longa e complexa a interação, mais tokens são consumidos e maior o custo. Em planos pagos, há limites de uso que podem ser atingidos rapidamente em sessões intensivas de análise de dados ou revisão de textos longos.

Uma recomendação importante: use sempre o modelo mais poderoso disponível. A diferença de qualidade entre modelos menores e maiores é substancial, especialmente para tarefas que exigem raciocínio — como análise estatística, revisão de argumentos e depuração de código. Um modelo mais fraco pode parecer funcional, mas comete erros sutis com mais frequência.

Para alunos da USP, o Gemini está disponível gratuitamente com o e-mail institucional (@usp.br), o que o torna o ponto de partida natural. As alternativas pagas mais comuns são o plano Pro do Claude (Anthropic) e o plano Plus do ChatGPT (OpenAI)¹. A OpenAI tem concedido temporariamente maior liberalidade no consumo de tokens, o que pode torná-la uma alternativa atrativa no curto prazo — mas é bom ficar atento, pois essas condições podem mudar rapidamente.

3.5.4 Limites e cuidados

É importante tratar agentes de IA como assistentes, não como substitutos do pesquisador. Alguns cuidados fundamentais:

Verificação: sempre verifique os resultados produzidos pelo agente. LLMs podem gerar código com erros sutis ou texto com afirmações incorretas (“alucinações”).
Compreensão: não use código que você não entende. O agente pode gerar uma análise complexa, mas você precisa saber explicar e defender cada escolha metodológica.
Transparência: se usar agentes de IA no seu trabalho, seja transparente sobre isso. Muitas revistas e programas de pós-graduação já possuem políticas sobre o uso de IA.
Reprodutibilidade: o uso de agentes não substitui a necessidade de documentar o workflow. Ao contrário, torna ainda mais importante ter scripts organizados e um replication package, pois o processo de geração do código precisa ser rastreável.

3.6 Exercícios

3.6.1 Git e GitHub

(Fácil) Crie uma conta no GitHub (se ainda não tiver). Configure o Git no seu computador com seu nome e e-mail usando o terminal.
(Fácil) No GitHub, crie um novo repositório chamado “exercicio-stat-basica”. Clone o repositório no RStudio usando File > New Project > Version Control > Git.
(Médio) No projeto clonado, crie um arquivo analise.R com qualquer código R simples. Faça o ciclo completo: stage, commit (com uma mensagem descritiva) e push. Verifique no GitHub se o arquivo apareceu.
(Médio) Modifique o arquivo analise.R, adicionando mais linhas de código. Faça um novo commit e push. No GitHub, explore o histórico de commits para ver as diferenças entre as versões.
(Médio) No repositório do exercício anterior, crie uma branch chamada experimento. Nessa branch, modifique o arquivo analise.R com alguma mudança (por exemplo, troque a função usada). Faça commit na branch experimento, volte para a main e verifique que o arquivo está inalterado. Depois, faça o merge da branch experimento na main.
(Difícil) Crie uma worktree a partir do seu repositório: git worktree add ../exercicio-worktree experimento. Abra a pasta criada no RStudio como um novo projeto e verifique que os arquivos correspondem à branch experimento. Faça uma modificação, commit, e volte ao projeto original para confirmar que o commit aparece no histórico. Depois, remova a worktree com git worktree remove.

3.6.2 R Markdown

(Fácil) Crie um novo arquivo R Markdown no RStudio (File > New File > R Markdown). Escolha o formato HTML. Clique em “Knit” sem fazer alterações e observe o documento gerado.
(Médio) No arquivo .Rmd criado, adicione: (a) um parágrafo com texto em negrito e itálico; (b) uma lista numerada; (c) um chunk de código R que calcule a média de um vetor qualquer. Renderize o documento.
(Médio) Crie um documento R Markdown que importe o banco dados/pib_cid.RDS, apresente uma tabela com as 10 primeiras linhas (usando kable()) e um gráfico de sua escolha. Use a opção echo = FALSE nos chunks para esconder o código no documento final.
(Difícil) Crie um documento R Markdown com formato PDF (requer LaTeX instalado) que inclua: (a) uma fórmula da média aritmética usando LaTeX; (b) um chunk que calcule a média do PIB per capita dos municípios; (c) uma referência inline ao resultado (usando `r `). O documento deve mostrar a fórmula, o código e o resultado integrados.

3.6.3 Workflow

(Médio) Crie a estrutura de pastas de um projeto de pesquisa seguindo a convenção apresentada neste capítulo (data/raw/, data/processed/, scripts/, outputs/, paper/). Dentro de scripts/, crie dois arquivos vazios: 01_clean.R e 02_analysis.R. Inicialize o projeto como repositório Git e faça o primeiro commit.
(Difícil) Monte um mini replication package: (a) coloque um arquivo CSV na pasta data/raw/; (b) em 01_clean.R, importe os dados, faça alguma transformação simples (filtro, criação de variável) e salve o resultado em data/processed/; (c) em 02_analysis.R, carregue os dados transformados e gere uma tabela ou gráfico, salvando em outputs/; (d) escreva um README.md com instruções de reprodução. Faça commit e push de tudo para o GitHub.

Disclaimer: minha companheira é sócia de uma consultoria que tem como cliente a OpenAI. Acredito que minhas análises não foram contaminadas, mas o leitor deve saber disso ao considerar minha avaliação.↩︎

Comando	Resultado
`\frac{a}{b}`	\(\frac{a}{b}\)
`\sqrt{x}`	\(\sqrt{x}\)
`\sum_{i=1}^{n}`	\(\sum_{i=1}^{n}\)
`\bar{x}`	\(\bar{x}\)
`\hat{\beta}`	\(\hat{\beta}\)
`\alpha, \beta, \mu, \sigma`	\(\alpha, \beta, \mu, \sigma\)
`\leq, \geq, \neq`	\(\leq, \geq, \neq\)