Ententendo o histórico do Git

O Git representa o histórico de uma maneira totalmente diferente dos sistemas de controle de versão centralizados (CVCS), como o Controle de Versão do Team Foundation, Perforce ou Subversion. Os sistemas centralizados armazenam um histórico separado para cada arquivo em um repositório. O Git armazena o histórico como um gráfico de instantâneos de todo o repositório. Esses instantâneos, chamados de commits no Git, 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 é muito importante e é a principal razão pela qual os usuários familiarizados com o CVCS acham que o Git é confuso.

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

Comece com um exemplo simples de histórico: um repositório com três commits 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. 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 fundamental no Git em comparação com o CVCS é que o desenvolvedor tem sua própria cópia completa do repositório. Ele precisa manter seu repositório local sincronizado com o repositório remoto, obtendo os commits mais recentes do repositório remoto. Para fazer isso, ele pode extrair o branch principal com o seguinte comando:

git pull origin main

Isso mescla todas as alterações do branch principal no repositório remoto, que o Git chama de origin por padrão. Essa extração trouxe um novo commit, e o branch principal no repositório local para para esse commit.

Entendendo o histórico do branch

Agora é hora de fazer uma alteração no código. É comum ter vários branches ativos ao trabalhar 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

Este é um atalho que combina dois comandos:

• git branch cool-new-feature para criar o branch
• git checkout cool-new-feature para começar a trabalhar no branch

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

Os commits podem ser acessados pelo branch cool-new-feature, uma vez que foram confirmados para esse branch. Agora que o recurso está pronto, ele precisa ser mesclado no branch principal. Para isso, use o seguinte comando:

git merge cool-new-feature main

A estrutura de gráfico do histórico fica visível quando há uma mesclagem. O Git cria um novo commit quando o branch é mesclado em outro. Isso é uma confirmação de mesclagem. Não há nenhuma alteração incluída neste commit de mesclagem, já que não houve conflitos. Se houvesse conflitos, o commit de mesclagem incluiria as alterações necessárias para resolvê-los.

História no mundo real

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

Próximas etapas

Saiba mais sobre como trabalhar com o histórico do Git no GitHub e Azure Repos ou simplificação do histórico do log do Git.