Ferramentas de
precisão cirúrgica.

Aponte para qualquer commit com ancestralidade exata, intervalos e Reflog

Em um commit de merge que uniu duas branches, um colega digita git show HEAD~2 achando que é a mesma coisa que git show HEAD^2 — e acaba inspecionando o commit errado. Qual é a diferença exata entre o circunflexo (^) e o til (~)?

Reflog, ancestralidade (^ vs. ~) e intervalos de commits

Na Seção 7.1, os autores ensinam todas as maneiras de referenciar um commit sem precisar copiar os 40 caracteres do SHA-1. Você pode usar apenas os primeiros caracteres não ambíguos (no mínimo 4, geralmente 7 a 10 caracteres exibidos com `git log --abbrev-commit`), descobrir o hash exato para o qual qualquer branch aponta com git rev-parse main ou consultar o histórico silencioso que o Git mantém nos bastidores: o Reflog (git reflog).

Enquanto você trabalha, o Git grava em um diário exclusivamente local toda vez que a ponta do seu `HEAD` ou de uma branch muda (seja por commit, checkout, merge ou até um `reset --hard`). Com git reflog (ou `git log -g`), você pode inspecionar onde estava há cinco movimentos (git show HEAD@{5}) ou onde uma branch estava ontem (git show main@{yesterday}), tornando quase impossível perder um commit já gravado localmente.

Já nas referências de ancestralidade, entender a diferença entre ^ e ~ é essencial quando há commits de merge (que possuem mais de um pai):

# 1. Crie um laboratório para a Etapa 3 com um merge commit para testar HEAD^2 vs. HEAD~2:
mkdir -p ~/lab-git-etapa3 && cd ~/lab-git-etapa3
git init -b main
echo "base 1" > app.txt && git add app.txt && git commit -m "C1: Commit avo na main"
echo "base 2" >> app.txt && git commit -a -m "C2: Commit pai na main"
git checkout -b lateral HEAD~1
echo "ramo lateral" > lateral.txt && git add lateral.txt && git commit -m "C3: Commit na branch lateral"
git checkout main && git merge lateral -m "C4: Merge da branch lateral"

# 2. Compare o avô na linha principal (HEAD~2) com o segundo pai vindo do merge (HEAD^2):
git show --oneline -s HEAD~2
git show --oneline -s HEAD^2

# 3. Veja o diário de movimentos locais no Reflog e use diferença simétrica com --left-right:
git reflog
git log --oneline --left-right main...lateral

Conexão com o livro · Capítulo 7 (Seção 7.1) · Short SHA-1, git rev-parse, git reflog (@{n}, @{yesterday}), ancestralidade (^ vs. ~) e intervalos (.., --not, ... com --left-right).

Prepare trechos de arquivos com git add -p, use Stash criativo e limpe com git clean

Você se empolgou codificando e resolveu dois bugs diferentes dentro do mesmo arquivo `pagamento.py`. Como colocar apenas as linhas do primeiro bug no commit de agora e deixar as linhas do segundo bug para o próximo commit sem precisar apagar código?

Staging Interativo por Hunks (git add -p)

Na Seção 7.2, Chacon e Straub apresentam uma das ferramentas favoritas de quem preza por commits limpos: o Staging Interativo (git add -i ou diretamente git add -p / --patch). Em vez de colocar o arquivo inteiro na Staging Area de uma só vez, o comando `git add -p` analisa o arquivo modificado e pergunta trecho por trecho (hunk by hunk): Stage this hunk [y,n,q,a,d,s,e,?]?.

Você digita y para preparar aquele trecho, n para deixá-lo fora do stage, s (split) para dividir um trecho grande em blocos menores ainda ou e para editar manualmente as linhas que entrarão no stage! E o mesmo modo `--patch` funciona para desfazer partes do arquivo: git reset -p (ou `git restore -p --staged`) tira trechos específicos da Staging Area, e `git checkout -p` (ou `git restore -p`) descarta trechos específicos na Working Tree.

Stash avançado (--index, --keep-index, -u) e limpeza segura (git clean)

Na Seção 7.3, quando você precisa trocar de branch imediatamente sem commitar o trabalho pela metade, o git stash (ou `git stash push`) guarda as modificações da Working Tree e da Staging Area em uma pilha local e deixa seu diretório limpo. Mas o livro vai muito além do básico com cinco variações decisivas:

# 1. Pratique o staging parcial por trechos (digite y para o primeiro trecho e n para o segundo):
#    git add -p app.txt
#    git diff --staged
#    git diff

# 2. Crie um arquivo novo não rastreado e guarde tudo na pilha com git stash -u:
cd ~/lab-git-etapa3
echo "trabalho em andamento" >> app.txt
echo "rascunho novo" > novo.txt
git stash push -u -m "WIP: ajuste parcial + arquivo novo"
git stash list

# 3. Restaure o trabalho preservando o estado do índice ou crie uma branch direto do stash:
git stash apply --index
git stash drop

# 4. Sempre simule com -n (dry-run) antes de limpar arquivos untracked com git clean:
git clean -d -n

Conexão com o livro · Capítulo 7 (Seções 7.2 e 7.3) · git add -i / -p, git stash (list, apply --index, pop, --keep-index, -u, --patch, branch) e git clean (-d, -n, -f, -x, -i).

Assine seu trabalho com GPG e investigue funções com git grep e git log -L

Como provar criptograficamente que um commit ou lançamento não foi adulterado, e como ver no terminal toda a evolução histórica de uma única função `calcular_imposto` sem ler mudanças no resto do arquivo?

Assinatura criptográfica GPG em Tags, Commits e Merges

Na Seção 7.4, aprendemos que, embora o Git garanta integridade com SHA-1, qualquer pessoa pode configurar qualquer nome e e-mail no `git config`. Para provar autenticidade criptográfica, você configura sua chave privada GPG (`git config --global user.signingkey `) e passa a assinar:

1. Tags assinadas (git tag -s v1.5 -m "..."): substitui o `-a` por `-s` para anexar a assinatura PGP ao objeto da tag, verificável por qualquer colega que tenha sua chave pública com git tag -v v1.5.
2. Commits assinados (git commit -S -m "..."): no Git 1.7.9+, assina o próprio commit. Você audita as assinaturas com git log --show-signature -1 ou inclui o indicador %G? no formato do log (`G` para assinatura válida, `B` para inválida, `U` para confiabilidade desconhecida e `N` para sem assinatura).
3. Exigir assinatura no Merge (git merge --verify-signatures -S): recusa mesclar uma branch se os commits recebidos não possuírem assinatura GPG válida e já assina o commit de merge resultante.

Busca instantânea com git grep (-p) e evolução de função com git log -L

Na Seção 7.5, em vez de usar um `grep` comum que varre até arquivos ignorados e pastas `.git`, use git grep, que busca apenas nos arquivos rastreados pelo seu repositório (ou até em uma tag antiga sem fazer checkout dela!). Combine -n para ver o número da linha, --count (`-c`) para resumir quantas ocorrências há por arquivo e a flag especial git grep -p <termo> (`--show-function`), que exibe automaticamente o cabeçalho da função ou método onde a linha foi encontrada!

E quando quiser ver como uma função específica ou um intervalo de linhas mudou desde que foi criado, use o Line Log Search (git log -L): executar git log -L :nome_da_funcao:caminho/arquivo.py (ou git log -L 10,25:caminho/arquivo.py) rastreia todos os commits e diffs que alteraram especificamente aquela função ao longo do tempo.

# 1. Crie um arquivo de código no laboratório e busque com número de linha (-n) e contexto de função (-p):
cd ~/lab-git-etapa3
cat << 'EOF' > calculo.py
def calcular_frete(peso):
    taxa_base = 15
    return peso * 2 + taxa_base
EOF
git add calculo.py && git commit -m "Adiciona funcao calcular_frete"
sed -i 's/taxa_base = 15/taxa_base = 20/' calculo.py
git commit -a -m "Reajusta taxa_base do frete para 20"

# 2. Encontre o termo exibindo em qual função ele mora (-p) e busque até em uma revisão específica:
git grep -n -p "taxa_base"
git grep --count "taxa_base"

# 3. Veja a história evolutiva EXCLUSIVA da função calcular_frete com git log -L:
git log -L :calcular_frete:calculo.py

# 4. Formato de auditoria de assinaturas GPG no log (%G?):
git log --pretty="format:%h [%G?] %aN - %s"

Conexão com o livro · Capítulo 7 (Seções 7.4 e 7.5) · GPG (user.signingkey, tag -s/-v, commit -S, --show-signature, %G?, --verify-signatures), git grep (-n, -c, -p, --and) e git log -L.

Curadoria de histórico com Rebase Interativo (git rebase -i)

Enquanto desenvolvia uma funcionalidade local, você criou quatro commits: o primeiro com a lógica principal, o segundo mexendo no README + outro módulo junto, o terceiro corrigindo um erro de digitação do primeiro e o quarto com mensagem provisória. Como transformar esses quatro rascunhos em dois commits impecáveis antes do git push?

Como funciona o roteiro do git rebase -i HEAD~3

Na Seção 7.6, Chacon e Straub ensinam a editar commits locais antes de compartilhá-los. Para alterar apenas o último commit, basta `git commit --amend` (ou `git commit --amend --no-edit` para somar arquivos esquecidos mantendo a mensagem). Mas para editar, reordenar, fundir ou dividir múltiplos commits anteriores, você usa o Rebase Interativo: git rebase -i HEAD~3 (para revisar os últimos 3 commits).

Atenção a um detalhe fundamental que evita erros: enquanto o `git log` lista os commits do mais novo no topo para o mais antigo embaixo, o editor do git rebase -i lista os commits na ordem cronológica de execução (do mais antigo no topo para o mais recente embaixo)! Ao mudar a palavra à esquerda do hash de cada linha, você comanda o que o Git fará na reaplicação:

# 1. Veja os últimos 3 commits na ordem normal do log vs. a ordem que o rebase -i usará:
cd ~/lab-git-etapa3
git log --pretty=format:"%h %s" -3

# 2. Como DIVIDIR um commit em dois quando o rebase -i parar em uma linha marcada com "edit":
#    (Depois de marcar o commit com "edit" no git rebase -i HEAD~3 e salvar):
#    git reset HEAD^
#    git add README.md && git commit -m "Atualiza formatacao do README"
#    git add lib/app.py && git commit -m "Adiciona funcao de auditoria"
#    git rebase --continue

# 3. A opção nuclear para apagar um arquivo de senhas que entrou em TODOS os commits da história:
#    git filter-branch --tree-filter 'rm -f senhas.txt' HEAD

Conexão com o livro · Capítulo 7 (Seção 7.6) · reescrita de histórico, git commit --amend (--no-edit), git rebase -i (pick, reword, edit, squash, fixup, drop), divisão de commits e filter-branch.

Desmistifique o git reset nas Três Árvores e simule o ganho na triagem

De comando temido a ferramenta previsível de manipulação de árvores

Na Seção 7.7 — uma das mais famosas de todo o livro Pro Git —, Chacon e Straub mostram que o comando `git reset` deixa de dar medo assim que você enxerga o Git gerenciando três árvores de arquivos distintas: o HEAD (o snapshot do último commit), o Index (o próximo snapshot proposto na Staging Area) e o Working Directory (os arquivos físicos no seu disco, que funcionam como uma bancada de edição).

Os três passos sequenciais do git reset (--soft, --mixed e --hard)

Quando você executa `git reset` apontando para um commit anterior (por exemplo, `HEAD~1`), ele sempre executa até três passos em ordem, parando onde a flag que você escolheu mandar parar:

1. Passo 1 · Mover a branch para onde o HEAD aponta (--soft para aqui): `git reset --soft HEAD~1` apenas move o ponteiro da branch atual um commit para trás. Ele não toca no Index nem no Working Directory! Isso significa que todas as mudanças daquele commit desfeito continuam prontas na Staging Area: se você rodar `git commit` agora, recriará exatamente o mesmo snapshot. É uma maneira rapidíssima de compactar os últimos 3 commits em um só (`git reset --soft HEAD~3 && git commit`).
2. Passo 2 · Atualizar o Index com o conteúdo do novo HEAD (--mixed para aqui — é o padrão!): quando você roda `git reset HEAD~1` (sem flag ou com `--mixed`), ele executa o Passo 1 e também atualiza a Staging Area para ficar igual ao commit anterior, mas não toca no Working Directory. Suas linhas de código continuam salvas no disco, apenas fora do stage.
3. Passo 3 · Sobrescrever o Working Directory (--hard vai até o fim — CUIDADO): `git reset --hard HEAD~1` executa os Passos 1 e 2 e, por último, sobrescreve os arquivos do seu disco para ficarem idênticos ao commit apontado. É a única variante do `reset` que destrói alterações locais ainda não commitadas.

# 1. Veja como compactar os últimos 2 commits em 1 usando apenas git reset --soft:
cd ~/lab-git-etapa3
echo "parte A" >> app.txt && git commit -a -m "Adiciona parte A"
echo "parte B" >> app.txt && git commit -a -m "Adiciona parte B"

# 2. Volte 2 commits mantendo todas as alterações de A e B já preparadas no Index (--soft):
git reset --soft HEAD~2
git status -s
git commit -m "Adiciona partes A e B consolidadas em um unico commit"

# 3. Se você fizer um reset --hard por engano em um commit já gravado, resgate pelo reflog:
git reflog -5

Simule o ganho operacional de usar as ferramentas avançadas do Capítulo 7

Na equipe de engenharia de plataforma coordenada por Bianca em Recife, cada ciclo de lançamento e diagnóstico resolvido com histórico limpo (`git add -p`, `git reset --soft` e `git bisect`) economiza R$ 260 em tempo de engenharia por sprint. O custo operacional de revisão e assinatura de commits consome R$ 65 por ciclo. Treinar a equipe nas ferramentas do Capítulo 7 e automatizar o script de busca binária custou R$ 520 iniciais. Quando alguém faz um reset destrutivo sem checar ou mistura alterações não relacionadas que exigem reconstrução manual da branch, cada incidente custa R$ 95.

Três casos em que entender as Três Árvores salva o dia

Conexão com o livro · Capítulo 7 (Seção 7.7) · Reset Demystified, The Three Trees (HEAD, Index, Working Directory), --soft, --mixed, --hard, reset com caminho e comparação com checkout.

Domine Merge Avançado, estilo diff3, reversão de merges (-m 1) e Subtree

Como desatar conflitos complexos e reverter um merge público sem perder a branch

Nas Seções 7.8 e 7.9, os autores abordam situações de merge em que o básico não basta: um colega converteu quebras de linha de Unix (LF) para Windows (CRLF) no arquivo inteiro gerando conflito em todas as linhas; você precisa ver o que havia no ancestral comum dentro do marcador de conflito; ou você precisa reverter na `main` um merge que já subiu para o servidor.

Cinco ferramentas para merges difíceis

1. Abortar ou ignorar mudanças de espaço em branco: se um merge deu errado e você quer voltar tudo ao estado anterior imediatamente, execute git merge --abort. Se o conflito veio apenas de diferenças de indentação ou quebra de linha (CRLF vs. LF), rode git merge -Xignore-space-change <branch> (ou `-Xignore-all-space`) para que a estratégia recursiva ignore espaçamento ao mesclar.
2. Ativar o estilo diff3 nos marcadores de conflito: por padrão, o conflito mostra apenas o que está em `HEAD` (`ours`) e o que veio da outra branch (`theirs`). Ao configurar git config --global merge.conflictstyle diff3 (ou passar `git checkout --conflict=diff3 `), o Git adiciona uma terceira seção central delimitada por ||||||| base mostrando como o trecho era no ancestral comum antes de qualquer um dos dois editar!
3. Inspecionar os estágios `:1:`, `:2:` e `:3:` e o Combined Diff (`--cc`): durante um conflito, o Index guarda três cópias de cada arquivo conflitante: estágio 1 (ancestral comum), estágio 2 (`ours` / `HEAD`) e estágio 3 (`theirs` / `MERGE_HEAD`), acessíveis via `git show :1:arquivo`, `:2:arquivo` e `:3:arquivo` (e comparáveis com `git diff --ours`, `--theirs` e `--base`). Já rodar `git diff` (ou `git log --cc -p -1`) exibe o formato Combined Diff com duas colunas de sinais `+` e `-`, mostrando apenas o que você alterou para resolver o conflito.
4. Reverter um commit de merge já publicado (git revert -m 1 HEAD) e a armadilha do re-merge: se um merge problemático já subiu para o servidor, você não deve usar `reset --hard`, e sim criar um commit inverso com git revert -m 1 HEAD (onde `-m 1` indica que o pai 1, a `main`, é a linha principal a ser mantida). Atenção à armadilha do livro: depois de reverter o merge, o histórico da `main` continua tendo os commits daquela branch como ancestrais! Se você corrigir o bug na branch `topic` e tentar rodar `git merge topic` de novo, o Git dirá Already up-to-date e ignorará todo o código que tinha sido revertido. Para trazer a branch de volta no futuro, você deve primeiro reverter o revert (`git revert `) e só então fazer `git merge topic`!
5. Preferência automática (`-Xours` / `-Xtheirs`) e Subtree Merging: se você quiser que o Git mescle tudo normalmente, mas escolha automaticamente o seu lado apenas nas linhas que derem conflito, use `git merge -Xours ` (diferente da estratégia radical `-s ours`, que descarta 100% do código da outra branch para fingir que já foi mesclada!). E com `git read-tree --prefix=pasta/ -u branch` + `git merge -Xsubtree=pasta`, você embute outro projeto inteiro dentro de uma subpasta.

# 1. Ative o estilo diff3 globalmente para sempre ver o ancestral comum (||||||| base) em conflitos:
git config --global merge.conflictstyle diff3

# 2. Durante qualquer conflito de merge, veja apenas os commits que tocaram nos arquivos em conflito:
#    git log --oneline --left-right --merge

# 3. Como reverter um merge público mantendo a main (pai 1) e como destravar o re-merge futuro:
#    git revert -m 1 HEAD
#    (Quando a branch topic estiver corrigida, reverta o commit de revert antes de mesclar de novo):
#    git revert 
#    git merge topic

Conexão com o livro · Capítulo 7 (Seções 7.8 e 7.9) · git merge --abort, -Xignore-space-change, estágios :1:/:2:/:3:, conflictstyle diff3, --cc, git revert -m 1, -Xours vs. -s ours, Subtree e Rerere.

Rastreie autoria com git blame -C e cace bugs automaticamente com git bisect

O sistema funcionava na versão `v1.0` há quinhentos commits, mas hoje está quebrado e ninguém sabe qual commit introduziu o defeito. Em vez de testar quinhentos commits um por um, como encontrar o culpado exato testando apenas nove commits — ou deixar um script encontrá-lo sozinho em segundos?

Anatomia de linha com git blame (-L e -C) e Busca Binária com git bisect

Na Seção 7.10, quando você sabe exatamente em qual arquivo e linha um bug está acontecendo e quer entender o contexto em que aquela linha foi escrita, use git blame -L 69,82 arquivo (restringindo a análise às linhas 69 a 82). Se o código daquele arquivo tiver sido refatorado ou movido de outro arquivo mais antigo, adicione a flag -C (git blame -C -L 141,153 arquivo): o Git analisa a base de código para descobrir de qual arquivo original aquele bloco de linhas foi copiado ou recortado, mostrando o autor e o commit originais da criação da lógica, e não apenas quem moveu o código de pasta!

Já quando você não faz ideia de qual arquivo quebrou o sistema, entra o git bisect. Ele executa uma busca binária entre um commit que você sabe que está quebrado (normalmente `HEAD`) e um commit antigo onde tudo funcionava (como `v1.0`). O Git faz checkout do commit exatamente na metade do caminho; você testa e diz `git bisect good` (se funcionou) ou `git bisect bad` (se já estava quebrado). A cada passo, o Git corta o número de suspeitos pela metade: em 1.000 commits, bastam no máximo 10 passos ($\log_2 1024 = 10$) para apontar o primeiro commit defeituoso! Ao terminar, sempre rode git bisect reset para voltar o `HEAD` à branch original.

# 1. Inspecione quem alterou um intervalo de linhas e de onde o bloco foi movido (-C):
cd ~/lab-git-etapa3
git blame -C -L 1,3 calculo.py

# 2. Fluxo manual do git bisect (iniciar -> marcar bad e good -> testar -> resetar):
#    git bisect start
#    git bisect bad HEAD
#    git bisect good C1
#    (teste o código e digite "git bisect good" ou "git bisect bad" até achar o culpado)
#    git bisect reset

# 3. Fluxo 100% AUTOMATIZADO com git bisect run:
#    Crie um comando ou script que retorne 0 quando o código está bom e 1 quando está ruim:
git bisect start HEAD C1
git bisect run grep -q "taxa_base = 15" calculo.py
git bisect reset

Teste de raciocínio: Automatizando o git bisect run

Para que o comando git bisect run ./testar-bug.sh funcione sem intervenção humana, o script precisa respeitar os códigos de saída (exit codes) esperados pelo Git. O código `0` informa que o commit atual é bom (`good`), e a maioria dos códigos entre `1` e `127` informa que o commit atual contém o bug (`bad`). Mas o que acontece se, no meio da busca binária, o Git cair em um commit antigo que nem sequer compila por outro motivo alheio ao bug que você está procurando? Qual código de saída especial o script deve retornar para mandar o Git pular (`skip`) aquele commit?

Para testar a transferência do conceito: se uma versão lançada há um mês teve 256 commits desde então e um teste automatizado leva 5 segundos para rodar, quanto tempo no máximo um `git bisect run` levará para apontar o commit exato que quebrou a funcionalidade?

Conexão com o livro · Capítulo 7 (Seção 7.10) · Debugging with Git, git blame (-L, -C para código movido/copiado) e git bisect (start, bad, good, skip, reset e bisect run com exit code 0/1/125).

Gerencie Submódulos, transfira commits offline com Bundle e armazene credenciais

Seu projeto principal depende de uma biblioteca interna que vive em outro repositório Git, ou você precisa enviar dez commits para um servidor isolado de fábrica que está sem acesso à rede externa. Como encerrar o Capítulo 7 dominando Submódulos, Bundles, Replace e Credenciais?

Submódulos sem armadilhas: clone recursivo, update --remote e push seguro

Na Seção 7.11, quando você precisa manter um repositório Git independente dentro de uma subpasta de outro repositório, você o adiciona com git submodule add <url>. Isso cria o arquivo de mapeamento .gitmodules e grava no projeto pai uma entrada especial de modo 160000 (que registra apenas o hash exato do commit em que o submódulo está apontado, e não os arquivos internos dele).

Quatro práticas recomendadas no livro evitam 99% das dores de cabeça com submódulos:

1. Clonar já trazendo os submódulos: use git clone --recurse-submodules <url> (ou, se já tiver clonado sem a flag, rode git submodule update --init --recursive).
2. Enxergar mudanças nos submódulos no status e no diff: configure git config --global diff.submodule log e git config status.submodulesummary 1 para que `git diff` e `git status` mostrem os commits novos do submódulo em vez de apenas hashes secos.
3. Atualizar e trabalhar dentro de um submódulo: por padrão, `git submodule update` deixa a subpasta em estado detached HEAD. Antes de editar código dentro do submódulo, entre na pasta dele e faça checkout de uma branch (`git checkout main`), e use git submodule update --remote --merge (ou `--rebase`) no projeto pai para puxar e integrar novidades.
4. Nunca esquecer de fazer push do submódulo antes do projeto pai: se você commitar no projeto pai apontando para um commit do submódulo que ainda só existe na sua máquina, mais ninguém conseguirá baixar o projeto! Use sempre git push --recurse-submodules=check (que bloqueia o push principal se faltar enviar o submódulo) ou git push --recurse-submodules=on-demand (que envia o submódulo automaticamente antes do projeto pai), além de rodar comandos em lote com git submodule foreach 'git stash'.

# 1. Empacote todo o seu repositório (ou uma faixa de commits) em um único arquivo binário (.bundle)
#    para transferir via pendrive/e-mail quando a rede ou o servidor estiver fora do ar (Cap. 7.12):
cd ~/lab-git-etapa3
git bundle create ~/meu-pacote.bundle HEAD main

# 2. Verifique a integridade do bundle e veja que é possível dar git clone ou git fetch direto do arquivo!
git bundle verify ~/meu-pacote.bundle
git bundle list-heads ~/meu-pacote.bundle
# git clone ~/meu-pacote.bundle ~/clone-do-bundle

# 3. Configure melhorias de visibilidade para submódulos e cache de credenciais HTTPS (Cap. 7.11 e 7.14):
git config --global diff.submodule log
# git config --global credential.helper 'cache --timeout=3600'

Git Bundle (Sneakernet), Git Replace e Credential Storage

As três últimas seções do Capítulo 7 (7.12 a 7.14) fecham a caixa de ferramentas:

Com git bundle create arquivo.bundle HEAD main (Seção 7.12), você empacota tudo o que normalmente passaria pelo cabo no `git push` dentro de um único arquivo binário portátil! Outro computador sem acesso ao servidor pode validar o arquivo com `git bundle verify` e executar `git clone arquivo.bundle` ou `git fetch ../commits.bundle main:outra-main` (podendo inclusive empacotar apenas uma faixa incremental de commits com `git bundle create commits.bundle main ^9a466c5`).

Já com git replace <commit-recente> <commit-historico> (Seção 7.13), você pode enxertar um repositório de histórico antigo na base de um repositório novo e truncado sem precisar reescrever os hashes SHA-1 dos commits recentes! E na Seção 7.14, para quem usa repositórios via HTTPS, o Credential Storage oferece os modos `cache` (guarda a senha apenas na memória RAM por 15 minutos ou pelo `--timeout` escolhido), `store` (grava em texto puro no disco, indicado apenas para ambientes protegidos) e os gerenciadores criptografados nativos do sistema (`osxkeychain` no macOS e `manager` no Windows).

Conexão com o livro · Capítulo 7 (Seções 7.11 a 7.15) · Submódulos (--recurse-submodules, foreach), git bundle (create, verify), git replace e Credential Storage.