Branches e equipe
sem atrito.

Entenda o que uma branch realmente é: blobs, árvores, commits e HEAD

Em sistemas antigos, criar uma branch de um projeto grande exigia copiar todos os arquivos para um novo diretório no servidor, o que podia levar vários minutos. Por que o Git cria uma branch de um projeto com cem mil arquivos em menos de um milissegundo?

A anatomia interna de um commit e o ponteiro de 41 bytes

Na Seção 3.1, Chacon e Straub abrem o modelo de dados do Git para explicar o segredo da velocidade das branches. Quando você executa git commit em um repositório com três arquivos, o Git grava no banco de dados um objeto blob para o conteúdo de cada arquivo, um objeto tree (árvore) que lista os nomes dos arquivos apontando para seus respectivos blobs, e um objeto commit que contém o nome do autor, a mensagem, o ponteiro para essa árvore raiz e o ponteiro para o commit imediatamente anterior (o parent ou pai). O primeiro commit da história tem zero pais; um commit normal tem um pai; e um commit de merge tem dois ou mais pais.

Com essa estrutura pronta, uma branch no Git é simplesmente um ponteiro leve e móvel para um desses commits — na prática, um pequeno arquivo dentro de .git/refs/heads/ contendo os 40 caracteres do hash SHA-1 do commit apontado mais uma quebra de linha (41 bytes no total!). Criar uma branch nova com git branch testing não copia nenhum arquivo do projeto: apenas grava um novo ponteiro de 41 bytes apontando para o commit onde você já está.

E como o Git sabe em qual branch você está trabalhando quando existem duas apontando para o mesmo commit? Ele mantém um ponteiro especial chamado HEAD. Quando você roda git branch testing, a branch é criada, mas o HEAD continua apontando para main. É somente quando você executa git checkout testing (ou o comando moderno git switch testing) que o HEAD passa a apontar para testing — e cada novo commit avança apenas a branch para a qual o HEAD aponta.

# 1. Crie um repositório de teste para observar o ponteiro HEAD e a divergência de branches:
mkdir -p ~/lab-git-etapa2 && cd ~/lab-git-etapa2
git init -b main
echo "versao base" > sistema.txt
git add sistema.txt && git commit -m "Commit inicial (f30ab)"

# 2. Crie a branch "testing", veja onde HEAD aponta com --decorate e troque para ela:
git branch testing
git log --oneline --decorate
git checkout testing
echo "mudanca na branch testing" >> sistema.txt
git commit -a -m "Adiciona experimento na testing"

# 3. Volte para a main, faça outra alteração e veja a árvore bifurcada com --all --graph:
git checkout main
echo "mudanca paralela na main" >> sistema.txt
git commit -a -m "Segue evolucao na main"
git log --oneline --decorate --graph --all

Conexão com o livro · Capítulo 3 (Seção 3.1) · objetos blob/tree/commit, ponteiros de branch, HEAD, git branch, git checkout (-b) / git switch (-c) e git log --decorate --graph --all.

Domine Fast-Forward, 3-Way Merge, conflitos e gestão de branches

Você está no meio do desenvolvimento do chamado #53 quando o telefone toca: há um erro crítico em produção que precisa ser corrigido em dez minutos. Como voltar à versão estável, publicar o reparo urgente e retomar o chamado #53 sem misturar os códigos?

A diferença entre Fast-Forward Merge e 3-Way Merge

Na Seção 3.2, os autores percorrem o cenário clássico que todo profissional vive na prática. Você está na branch iss53 com seus commits já salvos (ou guardados no stash, que veremos na Etapa 3) e faz checkout de volta para a branch de produção main. A partir dela, cria uma branch hotfix (`git checkout -b hotfix`), corrige o bug, faz o commit, volta para `main` e executa `git merge hotfix`.

Nesse primeiro merge, você verá a mensagem Fast-forward no terminal. Por quê? Porque o commit para onde `hotfix` aponta estava diretamente à frente do commit da `main`, sem que a `main` tivesse recebido outros commits paralelos nesse intervalo. O Git não precisa criar um commit novo de mesclagem: ele apenas desliza o ponteiro `main` para a frente!

Já quando você apaga a `hotfix` (`git branch -d hotfix`), volta para `iss53`, termina o trabalho e finalmente roda `git merge iss53` a partir da `main`, a situação é diferente: a `main` avançou com o `hotfix` e a `iss53` avançou por outro caminho. Como não há linha reta entre elas, o Git realiza um Three-Way Merge (mesclagem de três pontas) usando os dois snapshots das pontas das branches mais o snapshot do ancestral comum entre elas, criando automaticamente um novo merge commit com dois pais.

Como resolver um conflito de merge e limpar branches antigas

Quando ocorre um conflito (`CONFLICT (content): Merge conflict`), não há motivo para pânico: o Git ainda não criou o commit de merge e deixa claro no `git status` quais arquivos estão sob Unmerged paths. Dentro do arquivo conflitante, o Git delimita as duas versões:

1. Tudo entre <<<<<<< HEAD e ======= é o que estava na branch em que você estava quando rodou `git merge` (por exemplo, `main`).
2. Tudo entre ======= e >>>>>>> iss53 é o que veio da branch que você pediu para mesclar.
3. Para resolver, substitua todo o bloco (apagando completamente as linhas `<<<<<<<`, `=======` e `>>>>>>>`) pelo código final desejado, execute git add <arquivo> (que é a forma oficial de avisar ao Git que o conflito daquele arquivo foi resolvido) e rode git commit para concluir o merge.

Na Seção 3.3, mantenha o repositório limpo auditando suas branches com git branch -v (que mostra o último commit de cada uma), git branch --merged (que lista as branches já integradas na atual e que podem ser removidas com segurança usando git branch -d) e git branch --no-merged (que contém trabalho inédito e que o Git se recusa a apagar com `-d`, exigindo `-D` se você realmente quiser descartá-las).

# 1. No laboratório da Oficina 01, tente mesclar a branch "testing" na "main" (vai gerar conflito!):
cd ~/lab-git-etapa2
git checkout main
git merge testing

# 2. Veja o estado do conflito no git status e os marcadores <<<<<<<, ======= e >>>>>>> no arquivo:
git status
cat sistema.txt

# 3. Resolva o conflito gravando o texto consolidado, marque com git add e finalize o commit:
cat << 'EOF' > sistema.txt
versao base
mudanca paralela na main + experimento da testing integrados
EOF
git add sistema.txt
git commit -m "Resolve conflito integrando testing na main"

# 4. Audite quais branches já foram mescladas e apague a branch temporária com segurança:
git branch --merged
git branch -d testing

Conexão com o livro · Capítulo 3 (Seções 3.2 e 3.3) · Fast-Forward vs. 3-Way Merge, marcadores de conflito, git mergetool, git branch (-v, --merged, --no-merged, -d, -D, --move).

Coordene Topic Branches e Tracking Branches remotas

Seu colega diz que acabou de subir a branch serverfix para o servidor. Você roda git fetch origin, mas quando digita git branch ela não aparece na sua lista de branches locais. Onde ela foi parar e como começar a trabalhar nela?

Branches de longa duração, Topic Branches e referências origin/branch

Na Seção 3.4, Chacon e Straub contrastam dois usos complementares das ramificações: as Long-Running Branches (branches permanentes como main para código 100% estável e develop ou next para integração e testes de estabilidade) e as Topic Branches (branches curtas criadas para resolver uma única issue ou funcionalidade, que são mescladas e apagadas assim que passam nos testes).

Quando essas branches precisam ser compartilhadas com a equipe (Seção 3.5), entram em cena as Remote-Tracking Branches (como origin/main ou origin/serverfix). Elas são referências locais que você não consegue mover manualmente: funcionam como marcadores de página que lembram onde cada branch do servidor estava na última vez que você rodou git fetch ou git push.

Por isso, quando você roda git fetch origin e o servidor traz uma branch nova chamada serverfix, você não ganha automaticamente uma branch editável local chamada serverfix — você ganha apenas o ponteiro somente leitura origin/serverfix. Para criar uma branch local editável que rastreie (track) automaticamente essa referência remota, você usa uma Tracking Branch:

# 1. Publique uma topic branch local para o servidor remoto configurando o vínculo (-u):
git checkout -b serverfix
echo "correcao de timeout" > timeout.conf
git add timeout.conf && git commit -m "Ajusta timeout do servidor"
git push -u origin serverfix

# 2. Formas equivalentes de criar uma Tracking Branch local quando um colega publicou uma branch remota:
#    git checkout -b serverfix origin/serverfix
#    git checkout --track origin/serverfix
#    git checkout serverfix   (ou: git switch serverfix)

# 3. Audite todas as suas branches locais para ver quem está à frente (ahead) ou atrás (behind) do servidor:
git fetch --all
git branch -vv

# 4. Quando a topic branch já tiver sido mesclada na main, apague-a também no servidor remoto:
git checkout main
git merge serverfix
git push origin --delete serverfix

Observe a importância da combinação git fetch --all; git branch -vv explicada na Seção 3.5: o comando git branch -vv mostra para qual upstream cada branch aponta e informa se você está ahead 2 (tem 2 commits locais ainda não enviados) ou behind 1 (o servidor tem 1 commit que você ainda não mesclou). Porém, como o git branch -vv consulta apenas os dados já cacheados na sua máquina sem ir à internet, você deve sempre rodar git fetch --all imediatamente antes para ter números reais.

Conexão com o livro · Capítulo 3 (Seções 3.4 e 3.5) · Long-Running vs. Topic Branches, Remote-Tracking Branches, git checkout --track, git branch -u / -vv, @{u} e git push --delete.

Aplique Rebase para manter o histórico linear sem cair na sua armadilha

Sua branch de funcionalidade demorou três dias para ficar pronta e, nesse meio-tempo, a branch main recebeu dez commits da equipe. Quando você deve usar git rebase para deixar o histórico limpo e quando usar rebase causa um caos de commits duplicados para todo o time?

Como o Rebase funciona por dentro e o poder do --onto

Na Seção 3.6, aprendemos que existem duas formas de integrar mudanças entre duas branches: merge e rebase. Enquanto o git merge une apenas os snapshots finais das duas pontas e cria um commit de junção, o git rebase vai até o ancestral comum das duas branches, calcula o diff introduzido por cada commit da sua branch atual, guarda esses patches temporariamente, reposiciona sua branch na ponta da branch de destino (por exemplo, `main`) e reaplica cada alteração uma por uma em ordem.

O resultado final do código nos arquivos é exatamente o mesmo de um merge, mas o histórico de commits fica completamente linear — como se você tivesse escrito seus commits em série logo após o último trabalho da `main`, ideal antes de enviar uma contribuição para que o mantenedor consiga integrá-la com um simples fast-forward.

O livro também apresenta o rebase cirúrgico de três argumentos com git rebase --onto: imagine que você criou uma branch server a partir da `main` e, antes de `server` ficar pronta, criou uma sub-branch client a partir de `server`. Agora você quer levar para a `main` apenas os commits exclusivos de `client`, deixando os commits de `server` para depois. O comando git rebase --onto main server client diz literalmente ao Git: “Pegue a branch client, descubra os patches desde que ela divergiu de server e reaplique esses patches diretamente em cima da main”.

# 1. Crie uma branch "experiment" e faça os dois caminhos divergirem:
cd ~/lab-git-etapa2
git checkout -b experiment
echo "funcionalidade experimental" > exp.txt
git add exp.txt && git commit -m "Adiciona modulo experimental (C4)"

git checkout main
echo "atualizacao na main" >> sistema.txt
git commit -a -m "Atualiza base na main (C3)"

# 2. Faça o rebase da "experiment" sobre a ponta da "main" e conclua com Fast-Forward:
git checkout experiment
git rebase main
git checkout main
git merge experiment
git log --oneline --graph -4

# 3. Exemplo de sintaxe de transplante cirúrgico com --onto:
#    git rebase --onto main server client

A Regra de Ouro do Rebase: nunca reescreva commits públicos

Como o rebase abandona os commits antigos e cria commits novos com novos hashes SHA-1 para o mesmo código, Chacon e Straub resumem todos os perigos do rebase em uma única diretriz inegociável: Não faça rebase de commits que já existem fora do seu repositório e nos quais outras pessoas possam ter baseado trabalho. Se você fizer rebase de commits que já subiram para o servidor e outra pessoa já tiver puxado a versão antiga, ao fazer merge ela reenviará os commits antigos junto com os novos, duplicando o mesmo trabalho com dois hashes diferentes no histórico.

Conexão com o livro · Capítulo 3 (Seção 3.6) · rebase básico, git rebase --onto, The Perils of Rebasing, git pull --rebase e Rebase vs. Merge.

Escolha o fluxo distribuído certo, padronize commits e simule o ganho da equipe

Das arquiteturas de colaboração ao custo real dos conflitos de merge

Rafael coordena uma equipe de oito desenvolvedores em Porto Alegre que trabalhava em uma única branch compartilhada com entregas quinzenais. Como cada pessoa passava quatro ou cinco dias editando arquivos sem sincronizar e subia commits com erros de espaçamento e mensagens vagas, toda sexta-feira a equipe perdia horas destrinchando conflitos cruzados. Baseado nas Seções 5.1 e 5.2 de Pro Git, Rafael redesenha o fluxo da equipe.

Compare os três fluxos distribuídos e as regras de contribuição

Por ser distribuído, o Git permite três grandes topologias de colaboração no Capítulo 5.1:

1. Fluxo Centralizado (Centralized Workflow): há um único repositório central (`origin`) e toda a equipe tem permissão de push. Funciona bem para equipes pequenas ou médias, desde que cada funcionalidade nasça em uma Topic Branch isolada e seja revisada antes de entrar na `main`.
2. Fluxo com Gerente de Integração (Integration-Manager Workflow): cada desenvolvedor tem permissão de escrita no seu próprio fork público e apenas leitura no repositório oficial. O mantenedor oficial busca as branches dos colaboradores, testa localmente e faz o push para o repositório canônico (o modelo padrão do GitHub e GitLab).
3. Fluxo Ditador e Tenentes (Dictator and Lieutenants Workflow): variante para projetos com centenas de colaboradores (como o kernel Linux), onde tenentes integram subsistemas em seus repositórios e o ditador integra apenas as branches dos tenentes.

Independentemente da topologia, a Seção 5.2 estabelece as Commit Guidelines que determinam se suas contribuições serão aceitas rapidamente: primeiro, sempre execute git diff --check antes de commitar para flagrar espaços em branco sobrando no fim das linhas (trailing whitespace) ou mistura de tabs e espaços; segundo, faça commits atômicos (um commit por problema lógico); terceiro, escreva a mensagem com um resumo no modo imperativo de até 50 caracteres na primeira linha (ex.: Corrige arredondamento de frete em vez de Corrigi ou Corrigindo), seguido de uma linha em branco e uma explicação detalhada quebrada em cerca de 72 caracteres por linha.

# 1. Antes de criar qualquer commit, verifique se há erros de espaço em branco (trailing whitespace):
cd ~/lab-git-etapa2
printf "linha com espacos sobrando no final   \n" >> sistema.txt
git diff --check

# 2. Limpe o espaço sobrando e compare o que entrou em origin/main enquanto você trabalhava na sua branch:
sed -i 's/[[:space:]]*$//' sistema.txt
git diff --check

# 3. No fluxo de equipe privada (Cap. 5.2), inspecione os commits que chegaram em origin/main
#    e que ainda não estão na sua branch de trabalho atual:
#    git fetch origin
#    git log --no-merges issue54..origin/main

Meça o saldo operacional de adotar Topic Branches curtas

Na equipe de Rafael, cada funcionalidade concluída e integrada na `main` sem quebrar a versão gera um valor operacional de R$ 220 para o produto. O tempo de revisão de código e testes automatizados por branch consome R$ 60. Estruturar o guia de contribuição, treinar os oito desenvolvedores e configurar as proteções de branch custou R$ 480 iniciais. Porém, toda vez que uma branch fica longa demais, acumula conflitos mal resolvidos e exige que dois desenvolvedores parem para refazer o merge manualmente, esse incidente de conflito custa R$ 85.

A contribuição unitária é 220 − 60 = R$ 160 por entrega. Três entregas limpas (3 × 160 = R$ 480) cobrem o investimento inicial de implantação do fluxo. Com 9 funcionalidades entregues na sprint e apenas 1 conflito complexo de retrabalho (R$ 85), o saldo operacional fecha em 9 × 160 − 480 − 85 = R$ 875 positivos.

Três técnicas de contribuição distribuída do Capítulo 5.2

Conexão com o livro · Capítulo 5 (Seções 5.1 e 5.2) · fluxos Centralizado, Gerente de Integração e Ditador/Tenentes, git diff --check, regras de commit 50/72, merge --squash e format-patch.

Integre contribuições com diff de três pontos, cherry-pick, rerere e releases

Ferramentas de mantenedor para auditar, pinçar e lançar código com precisão

Na Seção 5.3, você assume o papel de quem mantém o repositório principal e precisa avaliar o código que outras pessoas enviaram antes de colocá-lo na `main`. Se você rodar um `git diff main contrib` comum (com dois pontos ou espaço), e a branch `main` tiver avançado desde que `contrib` nasceu, o diff mostrará todas as mudanças novas da `main` como se a branch `contrib` estivesse tentando apagá-las!

Quatro comandos que separam um usuário comum de um mantenedor experiente

1. A sintaxe de três pontos no diff (git diff main...contrib): ao usar reticências (`...`) entre duas branches no `git diff`, o Git encontra automaticamente o ancestral comum entre as duas branches (o mesmo que rodar `git merge-base contrib main`) e mostra exclusivamente o trabalho introduzido pela branch contrib desde que ela se separou da `main`, ignorando o que mudou na `main` depois. Já no `git log`, para listar os commits que estão em `contrib` mas não estão em `main`, você usa dois pontos (`git log main..contrib` ou `git log contrib --not main`).
2. Pinçar um único commit com git cherry-pick <sha>: um colaborador enviou uma branch com cinco commits, mas você quer trazer para a `main` apenas um commit específico de correção de bug sem mesclar os outros quatro. Basta estar na `main` e rodar `git cherry-pick e43a6`: o Git calcula o patch daquele único commit e o aplica como um commit novo na sua branch atual.
3. Memória automática de conflitos com git rerere (Reuse Recorded Resolution): ao ativar git config --global rerere.enabled true, o Git grava em cache a imagem antes e depois de cada conflito de merge que você resolve manualmente. Se você precisar refazer aquele merge mais tarde ou fazer rebase da mesma branch, o Git reconhece o mesmo conflito e aplica sua resolução anterior automaticamente!
4. Preparar a release oficial (`describe`, `archive` e `shortlog`): use git describe main para gerar um identificador de build legível a partir da última tag anotada (como `v1.6.2-rc1-20-g8c5b85c`, indicando 20 commits após a tag e o prefixo `g` do hash), git archive main --prefix='projeto/' --format=zip > release.zip para exportar um pacote limpo sem a pasta `.git` e git shortlog --no-merges v1.0.0..main para gerar o changelog agrupado por autor.

# 1. Ative o Reuse Recorded Resolution (rerere) globalmente na sua máquina:
git config --global rerere.enabled true

# 2. Crie uma branch de contribuição para testar o diff de 3 pontos (...) e o cherry-pick:
cd ~/lab-git-etapa2
git checkout -b contrib
echo "correcao pontual importante" > hotfix-pontual.txt
git add hotfix-pontual.txt && git commit -m "Corrige validacao de CPF"

# 3. Volte para a main, compare exatamente o que "contrib" introduziu com 3 pontos (...)
#    e pince o commit com git cherry-pick:
git checkout main
git diff main...contrib
git log --oneline main..contrib
git cherry-pick contrib

# 4. Gere uma tag anotada, um identificador de build (describe) e o resumo de lançamento (shortlog):
git tag -a v1.0.0 -m "Release 1.0.0"
git describe main
git shortlog --no-merges

Conexão com o livro · Capítulo 5 (Seção 5.3) · git apply (--check), git am (-3), git log --not / .., git merge-base, git diff ..., git cherry-pick, rerere, git describe, git archive e git shortlog.

Domine o GitHub Flow, Pull Requests iterativos e sincronização com Upstream

Você abriu um Pull Request no GitHub, o revisor pediu para renomear uma variável na linha 42 e um iniciante da equipe sugere fechar o Pull Request, apagar a branch e abrir outro do zero. Por que você nunca deve fechar o Pull Request para fazer ajustes?

Chaves SSH, Forks e o ciclo vivo de um Pull Request

Nas Seções 6.1 e 6.2, Chacon e Straub detalham o funcionamento do maior host de repositórios Git do mundo. O primeiro passo prático é configurar a autenticação por chave pública SSH (`~/.ssh/id_ed25519.pub` ou `~/.ssh/id_rsa.pub`) nas configurações da conta para não digitar credenciais a cada push, além de ativar a autenticação em dois fatores (2FA) e cadastrar todos os e-mails que você usa no seu `git config` para que seus commits sejam vinculados ao seu perfil.

Para colaborar, o GitHub Flow funciona tanto em repositórios externos (onde você cria um Fork pessoal na sua conta) quanto em projetos internos da empresa (onde todos usam branches no mesmo repositório):

1. Crie sempre uma Topic Branch a partir da `main` antes de escrever código (`git checkout -b slow-blink`). Nunca faça seus commits de contribuição diretamente na branch `main` do seu fork, pois isso dificulta enviar mais de um Pull Request independente ao mesmo tempo.
2. Envie sua branch para o seu remoto (`git push -u origin slow-blink`) e abra o Pull Request (PR) descrevendo a motivação da mudança com GitHub Flavored Markdown (usando listas de tarefas `- [x]`, blocos de código com destaque de sintaxe e referências como `Fixes #12` que fecham a Issue #12 automaticamente assim que o PR é aceito).
3. Iterando no Pull Request: se durante a revisão de código alguém pedir uma correção, você não fecha o PR! Basta fazer um novo commit na mesma branch local (`slow-blink`) e rodar `git push origin slow-blink`. O GitHub detecta o push e atualiza o Pull Request imediatamente, preservando todo o histórico dos comentários na revisão.

# 1. Configure o repositório original como remoto "upstream" para manter seu Fork sempre atualizado:
#    (Supondo que "origin" seja o seu fork e "upstream" seja o repositório oficial do projeto)
git remote add upstream https://github.com/organizacao/projeto-oficial.git

# 2. Busque as novidades do projeto oficial e configure sua branch main para puxar do upstream:
git fetch upstream
git checkout main
git branch --set-upstream-to=upstream/main main

# 3. Agora, sempre que quiser atualizar seu fork com o projeto oficial, bastam dois comandos:
git pull
git push origin main

Teste de raciocínio: Mantendo seu Fork em dia com o Upstream

Suponha que você fez um Fork do repositório `progit/progit2` para a sua conta `seu-usuario/progit2` há um mês. Hoje o repositório original está 5 commits à frente do seu fork. Você quer que, quando estiver na sua branch `main`, o comando `git pull` busque automaticamente do repositório oficial (`progit/progit2`), enquanto o comando `git push origin main` envie atualizações para o seu próprio fork. Resolva sem olhar acima: qual comando conecta sua `main` local ao remoto oficial?

Para testar a transferência do conceito: durante uma revisão de Pull Request no GitHub, qual é a diferença entre o mantenedor clicar em Merge pull request, Squash and merge ou Rebase and merge?

Conexão com o livro · Capítulo 6 (Seções 6.1 e 6.2) · configuração SSH/2FA, Forks, GitHub Flow, iteração em Pull Requests, remoto upstream, referências (#issue) e GitHub Flavored Markdown.

Inspecione referências refs/pull/, estruture a governança e automatize via API

Um colaborador externo abriu o Pull Request #958 no GitHub, mas você precisa rodar a bateria pesada de testes na sua estação local antes de aprovar — sem querer adicionar o fork dele manualmente como um novo remoto. Como o GitHub guarda cada Pull Request dentro do próprio repositório oficial?

O segredo das referências refs/pull/*/head e arquivos especiais

Na Seção 6.3, Chacon e Straub revelam um recurso de bastidores que pouquíssimos desenvolvedores conhecem: sempre que alguém abre um Pull Request em um repositório no GitHub, o servidor cria automaticamente uma referência interna chamada refs/pull/<numero>/head apontando para o commit exato daquele Pull Request (e `refs/pull//merge` apontando para o teste de merge com a branch alvo).

Por não começar com `refs/heads/`, essa referência não vem num `git clone` ou `git fetch` padrão, mas você pode listá-la com `git ls-remote` e baixá-la diretamente com git fetch origin refs/pull/958/head! Melhor ainda: se você adicionar a linha fetch = +refs/pull/*/head:refs/remotes/origin/pr/* na seção [remote "origin"] do seu arquivo .git/config, todo `git fetch` baixará todos os Pull Requests abertos e permitirá testar qualquer PR localmente digitando apenas git checkout pr/958! Além disso, adicionar `.patch` ou `.diff` ao final da URL de qualquer Pull Request no navegador (ex.: `https://github.com/usuario/repo/pull/1.patch`) entrega o patch pronto para aplicar com `git am`.

# 1. Veja todas as referências internas (incluindo refs/pull/) de um repositório remoto:
#    git ls-remote https://github.com/libgit2/libgit2

# 2. Configure seu .git/config para poder dar "git checkout pr/" em qualquer Pull Request:
git config --local --add remote.origin.fetch "+refs/pull/*/head:refs/remotes/origin/pr/*"
git config --local --get-all remote.origin.fetch

# 3. Exemplo de chamada à API REST do GitHub (Cap. 6.5) para obter um template oficial de .gitignore:
#    curl -s https://api.github.com/gitignore/templates/Python

Arquivos especiais (README e CONTRIBUTING), Organizações e Automação

Para escalar o trabalho em equipe (Seções 6.3 a 6.5), o capítulo destaca três pilares de governança:

1. Arquivos especiais na raiz do projeto: além do README.md (que apresenta o objetivo, instalação e licença na página inicial), criar um arquivo CONTRIBUTING.md faz com que o GitHub exiba automaticamente um banner com o link para as diretrizes da sua equipe toda vez que alguém abrir uma nova Issue ou um novo Pull Request.
2. Organizações, Times e Audit Log: em contas organizacionais, agrupe pessoas em Teams (como `@empresa/backend` ou `@empresa/seguranca`), que podem ser mencionados em comentários de PR exatamente como usuários individuais, aplique o menor nível de permissão necessário em cada repositório e audite eventos sensíveis (como transferências ou chaves adicionadas) no Audit Log.
3. Automação com Webhooks e GitHub API / Octokit: em vez de depender de verificações manuais, configure Webhooks para que o GitHub envie um payload JSON via HTTP POST a cada evento de `push` ou `pull_request` para o seu servidor de CI, e use a API (ou a biblioteca oficial Octokit) para atualizar o Status de Commit (verde/vermelho) diretamente na tela do Pull Request antes de liberar o botão de merge.

Conexão com o livro · Capítulo 6 (Seções 6.3 a 6.5) · URLs .patch, git ls-remote, refs/pull/*/head, README e CONTRIBUTING, Organizações/Teams, Webhooks, GitHub API e Octokit.