Entenda a história do Git

O Git representa o histórico de uma maneira fundamentalmente diferente dos sistemas de controles de versão centralizados (CVCS), como Team Foundation Version Control, 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 commits no Git, podem ter vários ascendentes, criando um histórico que se parece com um gráfico ao invés de uma linha reta. Essa diferença na história é incrivelmente importante e é a principal razão pela qual os usuários familiarizados com o CVCS acham o Git confuso.

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

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

O commit A é o pai do commit B e o commit B é o pai do commit C. Este histórico é muito semelhante a um CVCS. A seta apontando para confirmar C é uma ramificação. 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 o desenvolvedor tem sua própria cópia completa do repositório. Eles precisam manter seu repositório local sincronizado com o repositório remoto, obtendo as confirmações mais recentes do repositório remoto. Para fazer isso, eles puxam a ramificação principal com o seguinte comando:

git pull origin main

Isso mescla todas as alterações da ramificação principal no repositório remoto, que o Git nomeia origin por padrão. Este pull trouxe um novo commit, e a ramificação principal no repositório local move para esse commit.

Compreender a história da filial

Agora é hora de fazer uma alteração no código. É comum ter várias ramificações ativas ao trabalhar em diferentes recursos em paralelo. Isto contrasta fortemente com a CVCS, em que novas ramificações são pesadas e raramente são 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
• git checkout cool-new-feature para começar a trabalhar na filial

Dois ramos apontam agora para o mesmo compromisso. Suponha que haja algumas mudanças na cool-new-feature branch em dois novos commits, E e F.

Os compromissos são acessíveis pelo cool-new-feature ramo, uma vez que foram comprometidos com esse ramo. Agora que o recurso está pronto, ele precisa ser integrado no ramo principal. Para fazer isso, use o seguinte comando:

git merge cool-new-feature main

A estrutura gráfica do histórico torna-se visível quando há uma fusão. O Git cria um novo commit quando a ramificação é fundida com outra ramificação. Este é um compromisso de fusão. Não há nenhuma alteração incluída neste compromisso de mesclagem, uma vez que não houve conflitos. Se houvesse conflitos, o compromisso de fusão incluiria as alterações necessárias para resolvê-los.

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 a main filial ao mesmo tempo.

Próximos passos

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 log do Git.