Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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.
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.
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-featurepara criar o branch -
git checkout cool-new-featurepara começar a trabalhar no ramo
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.
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
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.
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.