Entendendo o histórico do Git

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

O Git armazena o histórico como um diagrama de instantâneos — chamados commits — de todo o repositório. Cada commit também contém um ponteiro para um ou mais commits anteriores. Os commits podem ter vários pais, criando um histórico que se parece com um gráfico em vez de uma linha reta. Essa diferença no histórico é incrivelmente importante e é o principal motivo pelo qual os usuários acham o Git confuso.

Observação

Se você não encontrar uma alteração no histórico do Git que você sabe que fez, saiba mais sobre como a simplificação do histórico do Git funciona em O Git perdeu minhas alterações: um panorama do histórico do Git.

Noções básicas do histórico de commits

Comecemos com um exemplo de histórico simples: um repositório com três confirmações lineares.

A confirmação A é o pai do commit B e a confirmação B é o pai da confirmação C. Esse histórico é muito semelhante a um CVCS. A seta que aponta para a confirmação C é um branch. Ele é nomeado main porque esse é o nome padrão para o branch central em um Repositório do Git. Os branches são ponteiros para confirmações específicas, e é por isso que a ramificação é tão leve e fácil no Git.

Uma diferença importante no Git em comparação com o CVCS é que tenho minha própria cópia completa do repositório. Preciso manter meu repositório local em sincronia com o repositório remoto obtendo os commits mais recentes do repositório remoto. Para fazer isso, efetuo pull do branch principal com o seguinte comando:

git pull origin main

Isso copia ("faz pull") todas as confirmações do branch main do repositório remoto (chamado origin por padrão) para o branch main do repositório local. A operação de pull copiou um novo commit e o branch main no repositório local agora está apontando para esse novo commit.

Entendendo o histórico do branch

Agora quero fazer uma alteração no meu código. É comum ter vários branches ativos nos quais você está trabalhando em diferentes recursos em paralelo. Isso contrasta fortemente com o CVCS, onde novos branches são pesados e raramente criados. A primeira etapa é fazer check-out para um novo branch usando o seguinte comando:

git checkout -b cool-new-feature

Esse é um atalho que combina dois comandos: git branch cool-new-feature para criar o branch seguido de git checkout cool-new-feature para começar a trabalhar no branch.

Dois branches agora apontam para o mesmo commit. Farei algumas alterações no branch cool-new-feature em dois novos commits, E e F.

Meus commits podem ser acessados pelo branch cool-new-feature pois os fiz nesse branch. Terminei com meu recurso e quero mesclá-lo em main. Para fazer isso, use o seguinte comando:

git merge cool-feature main

A estrutura de gráfico do histórico fica visível quando há uma mesclagem. O Git cria um novo commit quando mescla meu branch em outro branch. Isso é uma confirmação de mesclagem. Não há nenhuma alteração incluída neste commit de mesclagem, pois eu não tinha conflitos. Se eu tivesse conflitos, o commit de mesclagem incluiria as alterações necessárias para resolver esses conflitos.

História no mundo real

Aqui está um exemplo de histórico do Git que se assemelha mais ao código no desenvolvimento ativo em uma equipe. Há três pessoas que mesclam commits de seus próprios branches no branch principal ao mesmo tempo.

Agora que você entende como branches e mesclagens criam a forma do gráfico, isso não deve ser muito assustador!