Setup and Config

• git
• config
• help
• bugreport
• Credential helpers

Getting and Creating Projects

• init
• clone

Basic Snapshotting

• add
• status
• diff
• commit
• notes
• restore
• reset
• rm
• mv

Branching and Merging

• branch
• checkout
• switch
• merge
• mergetool
• log
• stash
• tag
• worktree

Sharing and Updating Projects

• fetch
• pull
• push
• remote
• submodule

Inspection and Comparison

• show
• log
• diff
• difftool
• range-diff
• shortlog
• describe

Patching

• apply
• cherry-pick
• diff
• rebase
• revert

Debugging

• bisect
• blame
• grep

Email

• am
• apply
• imap-send
• format-patch
• send-email
• request-pull

External Systems

• svn
• fast-import

Server Admin

• daemon
• update-server-info

Guides

• gitattributes
• Command-line interface conventions
• Everyday Git
• Frequently Asked Questions (FAQ)
• Glossary
• Hooks
• gitignore
• gitmodules
• Revisions
• Submodules
• Tutorial
• Workflows
• All guides...

Administration

• clean
• gc
• fsck
• reflog
• filter-branch
• instaweb
• archive
• bundle

Plumbing Commands

• cat-file
• check-ignore
• checkout-index
• commit-tree
• count-objects
• diff-index
• for-each-ref
• hash-object
• ls-files
• ls-tree
• merge-base
• read-tree
• rev-list
• rev-parse
• show-ref
• symbolic-ref
• update-index
• update-ref
• verify-pack
• write-tree

git-gc - Limpa os arquivos desnecessários e otimiza o repositório local

git gc [--aggressive] [--auto] [--[no-]detach] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]

Executa várias tarefas de limpeza no repositório atual, como a compactação dos arquivos das revisões (para reduzir o espaço em disco e aumentar o desempenho), a remoção dos objetos inacessíveis que podem ter sido criados a partir de invocações anteriores ao git add, pacotes refs, a remoção do "reflog", metadados reerere ou árvores de trabalho obsoletas. Pode também atualizar os índices auxiliares, como o grafo do commit.

Quando as operações porcelana tradicionais que criam os objetos são executadas, elas verificam se o repositório cresceu substancialmente desde a última manutenção e se for o caso, executam o o comando git gc automaticamente. Consulte gc.auto abaixo para saber como desativar este comportamento.

A execução manual do comando git gc só é necessária ao adicionar objetos em um repositório quando não executar regularmente estes comandos porcelana, para executar uma otimização única do repositório ou por exemplo, para limpar uma importação em massa que esteja abaixo do ideal. Consulte a seção "OTIMIZAÇÃO DE PACOTE" no git-fast-import[1] para obter mais detalhes sobre o caso de importação.

--aggressive

Normalmente, o comando git gc é executado muito rapidamente, proporcionando boa utilização do espaço em disco e bom desempenho. Essa opção fará com que o comando git gc otimize o repositório de forma mais agressiva, à custa de levar muito mais tempo. Os efeitos dessa otimização são, em sua maioria, persistentes. Consulte a seção "AGRESSIVO" abaixo para obter mais detalhes.

--auto

Com esta opção, o comando git gc verifica se é necessário alguma limpeza; caso contrário, sai sem fazer nada.

Consulte a opção gc.auto na seção "CONFIGURAÇÃO" abaixo para saber como essa heurística funciona.

Caso seja excedido os limites definidos nas opções de configuração como gc.auto e gc.autoPackLimit o processo de limpeza é acionado, todas as outras tarefas de limpeza (como rerere, árvores de trabalho, reflog…​, etc) também serão executados.

--[no-]detach

Run in the background if the system supports it. This option overrides the gc.autoDetach config.

--[no-]cruft

Ao expirar os objetos inalcançáveis, empacote-os separadamente num pacote simples em vez de armazena-los como objetos soltos. É predefinido que a opção --cruft esteja ativa.

--max-cruft-size=<n>

Ao empacotar objetos inalcançáveis num pacote de cruft, limite o tamanho dos novos pacotes de cruft para que tenham no máximo <n> bytes. Substitui qualquer valor especificado por meio da configuração gc.maxCruftSize. Consulte a opção --max-cruft-size do git-repack[1] para obter mais informações.

--expire-to=<diretório>

When packing unreachable objects into a cruft pack, write a cruft pack containing pruned objects (if any) to the directory <dir>. This option only has an effect when used together with --cruft. See the --expire-to option of git-repack[1] for more information.

--prune=<data>

Elimina objetos soltos mais antigos que a data (a predefinição é 2 semanas atrás, substituível pela variável de configuração gc.pruneExpire). A opção --prune=now remove objetos soltos independentemente de sua idade e aumenta o risco de corrupção se outro processo estiver gravando no repositório simultaneamente; consulte "NOTAS" abaixo. A predefinição é que a opção --prune sempre esteja ativada.

--no-prune

Não corte qualquer dos objetos soltos.

--quiet

Suprimir todos os relatórios de progresso.

--force

Imponha a execução do git gc mesmo que possa haver uma outra instância do git gc em execução neste repositório.

--keep-largest-pack

Todos os pacotes, exceto o maior pacote que não seja de rascunho, todos os pacotes marcados com um arquivo .keep e todos os pacotes de rascunho são consolidados num único pacote. Quando esta opção é utilizada, o gc.bigPackThreshold é ignorado.

Quando a opção --aggressive é utilizada, git-repack[1] será invocado com a opção -f, que por sua vez passará a opção --no-reuse-delta para git-pack-objects[1]. Isso descartará quaisquer deltas existentes e os computará novamente, às custas de se gastar muito mais tempo na re-embalagem.

Os efeitos disso são predominantemente persistentes, por exemplo, quando os pacotes e os objetos soltos são reunidos entre si, os deltas existentes neste pacote podem ser reutilizados, porém também existem vários casos onde em vez disso, podemos escolher um delta não otimizado de um pacote mais novo.

Além disso, utilizar --aggressive irá ajustar as opções --depth e --window encaminhadas para o git-repack[1]. Consulte as configurações gc.aggressiveDepth e gc.aggressiveWindow abaixo. Ao utilizar um tamanho de janela maior, é mais provável que encontremos deltas mais otimizados.

Provavelmente não vale a pena utilizar esta opção em um determinado repositório sem antes executar um benchmark de desempenho sob medida. Leva muito mais tempo e a otimização de espaço/delta resultante pode ou não valer a pena. Não utilizar isso de forma alguma é um dilema para a maioria dos usuários e seus repositórios.

Tudo abaixo desta linha nesta seção, está seletivamente incluído na documentação git-config[1]. O conteúdo é o mesmo que é encontrado ali:

O comando git gc evita muito a não exclusão dos objetos que possuam referencias em qualquer lugar do seu repositório. Ele manterá não apenas os objetos referenciados pelo seu conjunto atual das ramificações e as tags, mas também os objetos referenciados através do índice, as ramificações monitoradas remotamente, reflogs (que podem fazer referência no commit dos ramos que foram alterados ou retrocedido posteriormente) e qualquer outra coisa no espaço dos nomes refs/*. Observe que uma nota (do tipo criado através do git notes) anexada a um objeto não contribui para manter o objeto vivo. Caso esteja esperando que alguns objetos sejam excluídos e não foram, verifique todos estes locais e decida se faz sentido remover as referências ou não.

Por outro lado, quando o git gc é executado simultaneamente com outro processo, existe o risco de excluir um objeto que o outro processo está utilizando e que não criou uma referência para ele ainda. Isso pode causar falha no outro processo ou corromper o repositório caso o outro processo adicione posteriormente uma referência ao objeto excluído. O Git possui dois recursos que atenuam bastante este problema:

1. Qualquer objeto com um tempo de modificação mais recente que a data --prune é mantido, junto com tudo o que pode ser acessado.

2. A maioria das operações que adicionam um objeto ao banco de dados atualiza a hora da modificação do objeto, caso já esteja presente para que #1 se aplique.

No entanto, estes recursos ficam aquém de uma solução completa; portanto, os usuários que executam comandos simultaneamente, precisam enfrentar algum risco de corrupção (o que na pratica, o risco parece ser baixo).

O comando git gc --auto executará o gancho pre-auto-gc. Para mais informações consulte githooks[5].

git-prune[1] git-reflog[1] git-repack[1] git-rerere[1]

Parte do conjunto git[1]