Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022
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 semelhante a 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.
Observação
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 sobre o histórico de commits
Comece com um exemplo de histórico simples: um repositório com 3 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.
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
Isto copia ("puxa") todos os commits do ramo do repositório remoto (chamado main por definição padrão) para o ramo origin do repositório local. A operação de pull copiou um novo commit, e a branch main no repositório local agora aponta para este novo commit.
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. 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 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 na cool-new-feature ramificação em dois novos commits, E e F.
Os meus commits estão acessíveis pelo branch cool-new-feature, pois eu os fiz nesse branch.
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 um novo commit quando eu mesclo o meu ramo em outro ramo. Este é um compromisso de fusão. Não há alterações incluídas neste commit de fusão, pois não ocorreu nenhum conflito. 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 fazem a fusão dos commits dos seus próprios ramos 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!