Git: corrigindo bugs e consertando commits

Erro ao confirmar ... Como corrigi-lo? Uma bagunça na história dos commits ... Como fazer tudo parecer decente? O autor do artigo, cuja tradução estamos publicando hoje, diz que foi escrito especificamente para quem fez essas perguntas. Segundo ele, tendo estudado as técnicas para trabalhar com o Git apresentadas aqui, você pode avançar significativamente no caminho de dominar o Git.


Supõe-se que o leitor deste artigo já esteja familiarizado com o básico do Git. Caso contrário, é recomendável primeiro dominar a base, por exemplo, usando este material.

Corrigir bugs nas confirmações

Aqui, examinaremos vários cenários para erros nas confirmações e suas correções.

▍ Cenário número 1

Suponha que você tenha confirmado muitos arquivos e percebido que a mensagem de confirmação não estava muito clara. Depois disso, você decidiu alterar esta mensagem. Para fazer isso, use o git commit --amend . Aqui está um exemplo de sua aplicação:

 git commit --amend -m "New commit message" 

▍ Cenário número 2

Suponha que você deseje confirmar seis arquivos, mas comprometeu apenas cinco por engano. Parece que você pode corrigir esse erro simplesmente criando uma nova confirmação e adicionando o sexto arquivo ausente lá.

Essa abordagem tem direito à vida. Mas, para manter o histórico de consolidação em boas condições, provavelmente seria muito melhor poder adicionar um arquivo ignorado aleatoriamente ao mesmo commit. Isso pode ser feito, novamente, com o git commit --amend . Seu uso é assim:

 git add file6 git commit --amend --no-edit 

O sinalizador --no-edit significa que a mensagem de confirmação não muda.

▍ Cenário número 3

As confirmações feitas no Git estão vinculadas ao nome do autor e ao endereço de e-mail dele. Normalmente, esses dados são indicados executando a configuração inicial do Git. Como resultado, aqueles que usam o Git não podem, ao executar cada commit, se preocupar com as informações sobre seu autor.

Além disso, é bem possível que, ao trabalhar com alguns projetos, você precise usar informações sobre o autor, por exemplo, um endereço de e-mail diferente dos principais. Para esse projeto, você precisa especificar um endereço de email usando este comando:

 git config user.email "your email id" 

Suponha que você esqueceu de fazer essa configuração e já fez o primeiro commit. Corrigir a situação já pode familiar para nós equipe amend . Utilizando-o, você pode alterar as informações sobre o autor do commit anterior:

 git commit --amend --author "Author Name <Author Email>" 

▍ Nota

Use o comando de amend apenas em seu repositório local. Seu uso em repositórios remotos pode levar a uma enorme confusão.

Colocando ordem no histórico de confirmações

Suponha que você esteja trabalhando em um pedaço de código para um projeto. Você sabe que levará cerca de dez dias. Durante esses dez dias, outros desenvolvedores se comprometem com o repositório de origem.

É recomendável manter a sincronização entre os repositórios local e remoto. Isso evita os muitos conflitos de mesclagem que surgem quando os repositórios são muito raros para sincronizar. Seguindo essa prática, você decide baixar as alterações do repositório remoto a cada dois dias.

Sempre que você baixa o código de um controle remoto para um repositório local, uma nova consolidação de mesclagem é criada no repositório local. Isso significa que, no seu histórico de consolidação local, haverá muitas confirmações que podem confundir quem verá o seu código.


Histórico de confirmações no repositório local

Como arrumar o histórico de consolidação? Para resolver esse problema, você pode usar o git rebase .

Comando itGit rebase

Considere o git rebase como um exemplo.


Confirma no ramo Release e no ramo Feature

Existem três confirmações no ramo Release : Rcommit1 , Rcommit2 e Rcommit3 . Você criou o seu ramo Feature partir do ramo Release quando ele tinha apenas um commit - Rcommit1 . Depois disso, você adicionou duas confirmações ao ramo Feature . Estes são Fcommit1 e Fcommit2 . Seu objetivo é fazer o upload de confirmações da ramificação Release para a ramificação Feature . Para fazer isso, você usará o comando rebase .

Usaremos o release e o feature nomes para os dois ramos em consideração.

Como resultado, o uso do rebase terá a seguinte aparência:

 git checkout feature git rebase release 

▍ Recursos do comando rebase

O comando rebase usado para garantir que a ramificação Feature tenha um novo código da ramificação Release .

Ao aplicar esse comando, o sistema tenta adicionar cada confirmação à ramificação Feature , uma de cada vez, e verificar se há conflitos. Se isso parecer complicado, vejamos a figura a seguir. Isso mostra os mecanismos internos do rebase .


Ramificação de recursos e três etapas do comando rebase

Etapa 1

Quando o comando é chamado, o ramo Feature aponta para o cabeçalho do ramo Release . Depois disso, há três confirmações no ramo Feature : Rcommit1 , Rcommit2 e Rcommit3 . Talvez aqui você tenha uma pergunta sobre o que aconteceu com os Fcommit1 e Fcommit2 . Esses commits não desapareceram, eles serão usados ​​nas próximas etapas.

Etapa 2

Agora o Git está tentando adicionar o commit do Fcommit1 ao ramo Feature . Se não houver conflito, Fcommit1 adicionado após Rcommit3 . Se um conflito for detectado, o Git o reportará e você terá que resolvê-lo manualmente.

Etapa 3

Depois que o commit Fcommit1 adicionado ao ramo Feature , o Git tenta adicionar o Fcommit2 . Aqui, novamente, se não houver conflitos, o Fcommit2 adicionado após o Fcommit1 e a operação será concluída com êxito. Se um conflito for detectado, o Git, como antes, relatará isso e se oferecerá para lidar com isso.

Após a conclusão do comando rebase você pode ver que há confirmações Rcommit1 , Rcommit2 , Rcommit3 , Fcommit1 e Fcommit2 na ramificação Feature .

▍ Nota

Ao trabalhar com o Git, o comando merge e o comando rebase são rebase . Isso não quer dizer que um deles seja preferível ao outro.

Se você usar o comando merge , receberá uma confirmação de merge . Se você usar rebase , não terá nenhuma rebase adicional.

É recomendável que você use esses comandos em várias situações. Portanto, rebase é adequado para atualizar o código do repositório local com base no código mais recente do repositório remoto. Use o comando merge para executar solicitações pull para mesclar a ramificação Feature com a ramificação Release ou Master .

Sumário

Depois de estudar os conceitos apresentados neste artigo, você aprimorou suas habilidades em Git e está mais próximo do nível de um especialista em Git. Esperamos que o que você aprendeu aqui seja útil para você. Mas o mundo do Git é enorme, portanto, tendo dominado algo novo, não pare por aí e siga em frente.

Caros leitores! Você encontrou uma bagunça nos git commit?