Entenda a história do Git

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

O Git armazena o histórico como um gráfico de snapshots — 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 com um gráfico em vez de uma linha reta. Essa diferença na história é incrivelmente importante e é a principal razão pela qual os usuários acham o Git confuso.

Nota

Se você não consegue encontrar uma mudança no seu histórico do Git que você sabe que fez, saiba mais sobre como a simplificação do histórico do Git funciona no Git perdeu minhas alterações: Dando uma olhada na simplificação do histórico do Git.

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

Comece com um exemplo de histórico simples: um repositório com 3 confirmações lineares.

A confirmação A é o pai da confirmação B e a confirmação B é a controladora da confirmação C. Esta história é muito semelhante a um CVCS. A seta apontando para confirmar C é uma ramificação. Ele é nomeado main porque esse é o nome padrão para a ramificação principal em um repositório Git. As ramificações são ponteiros para compromissos específicos, 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 eu tenho minha própria cópia completa do repo. Preciso manter meu repositório local sincronizado com o repositório remoto obtendo as confirmações mais recentes do repositório remoto. Para fazer isso, puxarei a ramificação principal com o seguinte comando:

git pull origin main

Isso copia main ("pulls") todas as confirmações da ramificação do repositório remoto (chamado origin por padrão) para a main ramificação do repositório local. A operação pull copiou uma nova confirmação, e a main ramificação no repositório local agora está apontando para essa nova confirmação.

Compreender a história da filial

Agora quero fazer uma alteração no meu código. É comum ter várias ramificações ativas onde você está trabalhando em diferentes recursos em paralelo. Isso contrasta fortemente com a CVCS, onde novas filiais são pesadas e raramente criadas. A primeira etapa é fazer check-out em uma nova filial usando o seguinte comando:

git checkout -b cool-new-feature

Este é um atalho que combina dois comandos: git branch cool-new-feature para criar a ramificação seguida de git checkout cool-new-feature para começar a trabalhar na ramificação.

Dois ramos apontam agora para o mesmo compromisso. Vou fazer algumas alterações no cool-new-feature ramo em dois novos commits, E e F.

Meus compromissos são alcançáveis pelo cool-new-feature ramo desde que eu os fiz nesse ramo. Terminei meu recurso e quero mesclá-lo no main. Para fazer isso, usarei o seguinte comando:

git merge cool-feature main

A estrutura gráfica do histórico torna-se visível quando há uma fusão. O Git cria uma nova confirmação quando eu mesclei minha ramificação em outra ramificação. Este é um compromisso de fusão. Não há alterações incluídas nesta confirmação de mesclagem, pois não tive conflitos. Se eu tivesse conflitos, o compromisso de fusão incluiria as mudanças necessárias para resolver esses conflitos.

História no mundo real

Aqui está 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 fundem compromissos de suas próprias filiais para o ramo principal ao mesmo tempo.

Agora que você já entendeu como ramificações e mesclagens criam a forma do gráfico, isso não deve ser muito assustador!