Compartilhar via


Entender o histórico do Git

O Git representa o histórico de uma maneira fundamentalmente diferente dos CVCS (sistemas de controles de versão centralizados), como o Controle de Versão do Team Foundation, o Perforce ou o Subversion. Os sistemas centralizados armazenam um histórico separado para cada arquivo em um repositório. O Git armazena o histórico como um grafo de instantâneos de todo o repositório. Esses instantâneos, chamados de confirmações no Git, podem ter vários pais, criando um histórico que se assemelha a um grafo em vez de uma linha reta. Essa diferença no histórico é incrivelmente importante e é o principal motivo pelo qual os usuários familiarizados com o CVCS 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.

Três confirmações em uma linha

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. 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 o desenvolvedor tem sua própria cópia completa do repositório. Eles precisam manter seu repositório local em sincronia com o repositório remoto obtendo as confirmações mais recentes do repositório remoto. Para fazer isso, eles puxam o branch principal com o seguinte comando:

git pull origin main

Isso mescla todas as alterações do ramo principal no repositório remoto, que o Git denomina origin por padrão. Esse pull trouxe uma nova confirmação e o branch principal no repositório local é movido para essa confirmação.

Uma quarta confirmação, D, é adicionada à linha

Entender o histórico do branch

Agora é hora de fazer uma alteração no código. É comum ter várias ramificações ativas ao trabalhar 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
  • git checkout cool-new-feature para começar a trabalhar no ramo

Ramo cool-new-feature é adicionado

Dois branches agora apontam para a mesma confirmação. Suponha que haja algumas alterações na ramificação cool-new-feature em dois novos commits, E e F.

Adicionar confirmações a um ramo

As confirmações podem ser acessadas pelo cool-new-feature branch desde que foram confirmadas nesse branch. Agora que a funcionalidade está concluída, ela precisa ser integrada ao branch principal. Para fazer isso, use o seguinte comando:

git merge cool-new-feature main

Mesclar um branch

A estrutura de grafo do histórico fica visível quando há uma mesclagem. O Git cria um novo commit quando o branch é mesclado em outro branch. Essa é um commit de mesclagem. Não há nenhuma alteração incluída neste commit de mesclagem, pois 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

Aqui está um exemplo do 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 suas próprias ramificações na ramificação main no mesmo horário.

Log de console do git graph

Próximas etapas

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