Entender o histórico do Git

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

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

Noções básicas de histórico de confirmação

Comece com um exemplo de histórico simples: um repositório com três commits lineares.

Commit A é o pai do commit B e commit B é o pai do commit C. Esse histórico é muito semelhante a um CVCS. A seta que aponta para o commit C é um branch. Ele é nomeado main porque esse é o nome padrão para o branch de linha principal em um repositório Git. 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 as confirmações mais recentes do repositório remoto. Para fazer isso, vou fazer pull no branch principal com o seguinte comando:

git pull origin main

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

Entender o histórico do branch

Agora quero fazer uma alteração no meu código. É comum ter várias ramificações (branches) ativas nas quais você trabalha em diferentes funcionalidades em paralelo. Isso contrasta com o CVCS, em que novas ramificações são pesadas e raramente criadas. A primeira etapa é mudar para um novo ramo 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 por git checkout cool-new-feature para começar a trabalhar no branch.

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

Meus commits podem ser acessados pelo cool-new-feature branch desde que os fiz nessa ramificação. Terminei com meu recurso e quero mesclar em main. Para fazer isso, usarei o seguinte comando:

git merge cool-feature main

A estrutura de grafo do histórico fica visível quando há uma mesclagem. O Git cria um novo commit quando mesclo meu ramo em outro ramo. Essa é um commit de mesclagem. Não há nenhuma alteração incluída nesta confirmação de mesclagem, pois não tive conflitos. Se eu tivesse conflitos, a confirmação 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 confirmações de seus próprios branches no branch principal ao mesmo tempo.

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