Algumas outras boas referências sobre esses tópicos:
Eu uso o índice como um ponto de verificação .
Quando estou prestes a fazer uma alteração que pode dar errado - quando quero explorar uma direção que não tenho certeza se posso seguir adiante ou mesmo se é uma boa ideia, como uma refatoração ou mudança conceitual exigente tipo de representação - eu verifico meu trabalho no índice. Se esta é a primeira alteração que fiz desde a minha última confirmação, posso usar o repositório local como um ponto de verificação, mas geralmente tenho uma alteração conceitual que estou implementando como um conjunto de pequenas etapas. Desejo verificar o ponto após cada etapa, mas salve o commit até voltar ao trabalho, código testado.
Notas:
o espaço de trabalho é a árvore de diretórios dos arquivos (de origem) que você vê e edita.
O índice é um arquivo binário único e grande, <baseOfRepo>/.git/index
que lista todos os arquivos da ramificação atual, suas somas de verificação sha1 , registros de data e hora e o nome do arquivo - não é outro diretório com uma cópia dos arquivos.
O repositório local é um diretório oculto ( .git
), incluindo um objects
diretório que contém todas as versões de cada arquivo no repositório (ramificações locais e cópias de ramificações remotas) como um arquivo compactado "blob".
Não pense nos quatro 'discos' representados na imagem acima como cópias separadas dos arquivos de recompra.
Eles são basicamente referências nomeadas para confirmações do Git. Existem dois tipos principais de referências: tags e heads.
- Tags são referências fixas que marcam um ponto específico no histórico, por exemplo, v2.6.29.
- Pelo contrário, os chefes são sempre movidos para refletir a posição atual do desenvolvimento do projeto.
(observação: como comentado por Timo Huovinen , essas setas não são o que as confirmações apontam, é a ordem do fluxo de trabalho , basicamente mostrando as setas como 1 -> 2 -> 3 -> 4
onde 1
está o primeiro commit e 4
o último)
Agora sabemos o que está acontecendo no projeto.
Mas, para saber o que está acontecendo aqui e agora, há uma referência especial chamada HEAD. Serve para dois propósitos principais:
- informa ao Git qual commit para obter arquivos quando você faz o checkout e
- diz ao Git onde colocar novos commit quando você faz o commit.
Quando você o executa git checkout ref
, aponta HEAD
para o árbitro que você designou e extrai arquivos dele. Quando você executa, git commit
ele cria um novo objeto de confirmação, que se torna filho do atual HEAD
. Normalmente HEAD
aponta para uma das cabeças, então tudo funciona muito bem.
HEAD
é o commit na ponta da ramificação atual. Se você acabou de verificar a ramificação, ou seja, não possui arquivos modificados, seu conteúdo corresponde à árvore de trabalho. Assim que você modifica algo, ele não corresponde mais.