Git não é apenas uma coleção de comandos; é um sistema de controle de versões distribuído que registra o estado de um conjunto de arquivos através de snapshots imutáveis. Em termos internos, tudo é armazenado como objetos: blobs (conteúdo de arquivos), trees (árvores que organizam a hierarquia), commits (snapshots com metadados) e tags (marcas semânticas para pontos relevantes).

O repositório mantém referências que apontam para commits específicos — refs/heads/para branches, refs/remotes/ para repositórios remotos. O working tree representa o estado atual de trabalho, enquanto o index (staging area) é o espaço onde o próximo commit é composto. O design distribuído permite que cada clone carregue o histórico completo e opere offline, reunindo alterações de qualquer lugar.

• Snapshots imutáveis dos estados do repositório
• Objetos: blobs, trees, commits e tags
• Referências (heads, remotes) como ponteiros para commits
• Working tree, index e repositório formam o ciclo de trabalho

Os commits constituem um grafo acíclico orientado (DAG). Cada commit aponta para um ou mais pais, formando a história do projeto. Merges criam commits com múltiplos pais, preservando o contexto de integração. Como os objetos são referenciados por hashes, a identidade de cada snapshot depende do conteúdo, da árvore de diretórios e dos metadados do commit.

Esse grafo facilita operações de integração e auditoria, pois cada ponto de integração é uma referência fixa que pode ser examinada independentemente de como o repositório evoluiu depois. O reflog registra o histórico local de alterações em referências, permitindo recuperar estados mesmo após reescritas ou alterações de ponteiros.

• Commits apontam para pais; o grafo é acíclico
• Merges introduzem múltiplos pais, preservando o histórico de integrações
• Hashes de objetos garantem integridade e identidade do snapshot
• Reflog oferece observabilidade local das referências

Referências em Git são ponteiros mutáveis para commits específicos. Branches são ponteiros móveis que indicam o último commit de uma linha de desenvolvimento; remotes trazem referências de repositórios remotos (como origin). O conjunto de refs/heads e refs/remotes forma a base para entender a evolução de diferentes linhas de código.

A prática de trabalhar com branches envolve decisões sobre manter ou reescrever a história. O merge preserva a história de integrações, enquanto o rebase reescreve a sequência de commits para parecer uma linha única. Em termos conceituais, manter história clara facilita auditoria e reverts, enquanto rebase pode simplificar a narrativa de uma feature antes de integrá-la a um branch principal. Tags marcam pontos estáticos de referência para releases ou marcos.

• Branches são ponteiros móveis para commits
• Remotes trackam histórico de repositórios remotos
• Merges vs rebase: impacto na história compartilhada
• Tags diferenciam marcos estáveis

A base de tudo é a integridade dos dados: cada objeto é armazenado pelo seu conteúdo e pelo hash que o identifica. O Git não altera os objetos originais; ele cria novos snapshots conforme necessário. A observabilidade vem da capacidade de inspecionar o grafo, o histórico e as referências de forma detalhada.

Ferramentas de baixo nível verificam a consistência do repositório (por exemplo, através de checagens de objetos) e o gerenciamento de objetos não referenciados ao longo do tempo. Historicamente, isso se traduz em práticas como revisar histórico com visualizações de grafo, inspecionar alterações específicas de um commit e usar comandos para entender a origem de mudanças antes de avançar em integrações.

• Hashes garantem a integridade e identificam snapshots
• git fsck e gc ajudam na manutenção e limpeza
• Reflog permite recuperação e auditoria de estados anteriores
• História pode ser inspecionada com ferramentas de visualização de commits

Para provocar uma visão rápida do passado, um comando que exibe graficamente o histórico sem instruções de fluxo de trabalho é útil como referência conceitual:

git log --graph --oneline --decorate --all

Esse tipo de visualização ajuda a entender como diferentes linhas de desenvolvimento se cruzam ao longo do tempo, reforçando a ideia de que o Git é, acima de tudo, uma representação de snapshots conectados por um grafo de commits.