Saiba como desfazer alterações no Git usando o Bitbucket Cloud

À medida que você avançar no tutorial, vai ver diversos outros comandos git como parte do aprendizado de como desfazer alterações. Então, ao trabalho.

Vamos começar criando um repositório exclusivo com todo o código do original. Este processo é chamado "bifurcação de repositório". Bifurcar é um processo git estendido que é ativado quando um repositório compartilhado é hospedado com um serviço de hospedagem de terceiros como o Bitbucket.

1. Clique ou insira o seguinte URL: https://bitbucket.org/atlassian/tutorial-documentation-tests/commits/all

2. Clique no símbolo + na barra lateral esquerda e selecione Bifurcar este repositório, analise a caixa de diálogo e clique em Bifurcar repositório.

3. Você deve ser levado para a visão geral do novo repositório.

4. Clique no símbolo + e selecione Clonar este repositório.

5. No seu computador, clone o repositório.

6. Navegue para o diretório que contém o repositório clonado.

Agora que você tem um repositório cheio de códigos e um histórico no sistema local, já pode desfazer algumas alterações.

Você vai ter que encontrar e referenciar a alteração que quer desfazer. Isso pode ser feito navegando na interface de usuário do commit no Bitbucket e há alguns utilitários de linha de comando que podem localizar uma alteração específica.

Você vai ter que encontrar e referenciar a alteração que quer desfazer. Isso pode ser feito navegando na interface de usuário do commit no Bitbucket e há alguns utilitários de linha de comando que podem localizar uma alteração específica.

O resultado de git status mostra que tudo está atualizado com a ramificação principal remota e não há alterações pendentes aguardando commit. No próximo exemplo, a gente vai fazer umas edições no repositório e o examinar em um estado de alterações pendentes. Ou seja, você tem alterações em arquivos no repositório do sistema local que não foram preparadas para serem adicionadas ao histórico do projeto.

Para demonstrar este próximo exemplo, primeiro abra o arquivo myquote2.html. Faça algumas modificações no conteúdo de myquote2.html, salve e saia do arquivo. Vamos executar o git status mais uma vez para examinar o repositório neste estado.

O resultado mostra que o repositório tem modificações pendentes em myquote2.html. Ótimo! Se a modificação que você quer desfazer, como no exemplo acima, não tiver sido adicionada à área de staging ainda, você pode apenas editar o arquivo e seguir adiante. O Git só começa a rastrear uma alteração quando você a adiciona à área de staging e a confirma no histórico do projeto.

Vamos "desfazer" as alterações em myquote2.html. Como este é um exemplo simplificado com alterações mínimas, há dois métodos disponíveis para desfazer. Se a gente executar git checkout myquote2.html, o repositório vai restaurar myquote2.html para a versão já confirmada. Uma alternativa é executar git reset --hard, que vai reverter todo o repositório para o último commit.

O comando git log permite que você liste, filtre e busque no histórico do projeto por alterações específicas. Enquanto o git status permite que você inspecione o diretório de trabalho e a área de staging, o git log só exibe o histórico confirmado.

O mesmo registro do histórico confirmado pode ser encontrado na interface de usuário do Bitbucket acessando a exibição de "commits" de um repositório. A exibição de commits do repositório de demonstração se encontra em: https://bitbucket.org/dans9190/tutorial-documentation-tests/commits/all. Essa exibição vai ter um resultado parecido com o utilitário de linha de comando git log. Ela pode ser usada para encontrar e identificar um commit a ser desfeito.

No exemplo a seguir, você pode ver várias coisas no histórico, mas cada modificação é, na verdade, um commit, então é isso o que a gente precisa encontrar e desfazer.

Vamos ver um pouco mais de perto um dos commits na lista.

O que você pode ver é que cada mensagem de commit tem quatro elementos:

O mais provável é que a alteração que você quer desfazer vai estar em algum lugar mais para o fim do histórico do projeto, o que pode ser um tanto cansativo. Então, vamos aprender algumas operações básicas usando git log para encontrar uma alteração específica.

1. Vá até a janela de terminal e navegue pela parte superior do repositório local usando o comando cd (mudar de diretório).

Digite o comando git log --oneline. Adicionar --oneline vai exibir cada commit em uma linha só que permite visualizar mais históricos no terminal.

Pressione a tecla q para sair do log de commits e voltar ao prompt de comando quando quiser.

Você deve ver algo como o exemplo a seguir:

2. Pressione a tecla q para voltar ao seu prompt de comando.

3. Localize o commit com o hash c5826da e mais alterações na lista que o comando git log produziu. Alguém não escreveu uma mensagem de commit descritiva, então a gente vai ter que descobrir se as alterações necessárias estão aqui.

4. Destaque e copie o hash de commit c5826da do resultado do git log na janela de terminal.

5. Digite git show e cole ou transcreva o hash de commit que você copiou e pressione Enter. Você deve ver algo assim:

O prompt na parte inferior vai continuar sendo preenchido até que mostre toda a alteração. Pressione q para sair do prompt de comando.

Aqui você viu um resumo de como funciona o comando git log. Caso você goste de trabalhar com esse comando, confira o tutorial do git log avançado.

1. Digite git log --oneline na janela de terminal.

2. Copie o hash de commit do segundo commit no diretório log: 52f823c e depois pressione q para sair do Registro.

3. Digite git reset --soft 52f823c na janela de terminal. O comando deve ser executado em plano de fundo se for bem-sucedido. Pronto! Você desfez a primeira alteração. Agora, veja o resultado desta ação.

4. Digite git status na janela de terminal e você vai ver que o commit foi desfeito e agora é uma alteração não confirmada. Você deve ver algo assim:

5. Digite git log --oneline na janela de terminal. Você deve ver algo assim:

6. Você pode ver que o novo HEAD da ramificação é o commit 52f823c, o que é bem o objetivo.

7. Pressione q para sair do Registro. Deixe o terminal aberto, porque, agora que você aprendeu a fazer uma redefinição simples, a gente vai tentar algo um pouco mais complexo.

1. Digite git log --online

2. Copie o hash de commit 1a6a403 (myquote editado on-line com o Bitbucket) que é o commit logo abaixo da pull request nº 6 com as alterações que a gente quer desfazer.

3. Digite git reset 1a6a403 na janela de terminal. O resultado deve ser algo assim:

Você pode ver que as alterações estão em um estado não confirmado. Isso significa que a gente removeu várias alterações, tanto do histórico do projeto como da área de staging.

4. Digite git status na janela de terminal. O resultado deve ser algo assim:

Agora, você pode ver que a primeira alteração que a gente desfez (o arquivo bitbucket-pipelines.yml) não tem nenhum rastreamento pelo git. Isso acontece porque invocando git reset remove a alteração do cabeçalho da ramificação e do rastreamento da área de índice de git. O processo interno é um pouco mais complexo do que o conteúdo que a gente pode explicar aqui. Leia mais em git reset.

5. Digite git log --oneline na janela de terminal.

Agora, o resultado do log exibe que o histórico de commits também foi modificado e começa na confirmação 1a6a403. Para fins de demonstração e mais exemplos, a gente quer desfazer a redefinição que acabou de fazer. Depois de mais considerações, talvez a gente queira manter o conteúdo da pull request nº 6.

Git resets são um dos poucos métodos de "desfazer" que o Git oferece. Redefinições são, no geral, consideradas uma opção "insegura" para desfazer alterações. Elas são boas para trabalhar no local em códigos isolados, mas são arriscadas quando compartilhadas com membros da equipe.

Para compartilhar uma ramificação redefinida com uma equipe remota, um "push forçado" deve ser executado. Um "push forçado" é iniciado executando git push -f. Um envio por push forçado destrói qualquer histórico na ramificação que foi criada após o ponto do push.

A seguir, um exemplo desse cenário "inseguro":

• O desenvolvedor A está trabalhando em uma ramificação no desenvolvimento de uma nova função.
• O desenvolvedor B trabalha na mesma ramificação desenvolvendo uma função separada.
• O desenvolvedor B decide redefinir a ramificação para um estado anterior ao início do trabalho dos desenvolvedores A e B.
• O desenvolvedor B, então, envia a ramificação de redefinição forçada para o repositório remoto.
• O desenvolvedor A faz o pull da ramificação para receber atualizações. Durante esse pull, o desenvolvedor A recebe a atualização forçada. Isso redefine a ramificação local do desenvolvedor A para um momento anterior a qualquer trabalho de função e perde os commits.

O resultado de git reflog deve ser parecido com o que aparece acima. Você pode ver um histórico de ações no repositório. A linha superior é uma referência à redefinição que a gente fez para redefinir a solicitação pull nº 6. Vamos redefinir para restaurar a solicitação pull nº 6. A segunda coluna desse resultado de reflog indica um ponteiro de referência para uma ação de modificação feita no repositório. Aqui, HEAD@{0} é uma referência ao comando de redefinição que a gente já executou. É melhor não repetir esse comando de redefinição, então a gente vai restaurar o repositório para HEAD@{1}.

Vamos examinar o histórico de commits do repositório com git log --oneline:

Agora, o resultado do log exibe que o histórico de commits também foi modificado e começa na confirmação 1a6a403. Para fins de demonstração e mais exemplos, a gente quer desfazer a redefinição que acabou de fazer. Depois de mais considerações, talvez a gente queira manter o conteúdo da pull request nº 6.

Para este exemplo, vamos usar o commit 1f08a70 mais recente como o commit em que a gente vai operar. Para este contexto, digamos que a gente quer desfazer as edições feitas nesse commit. Execute:

Isso vai dar a partida no fluxo de trabalho git merge. O Git vai criar um commit novo com conteúdo que é uma reversão do commit especificado para a reversão. O Git, assim, vai abrir um editor de texto configurado para preparar para uma nova mensagem de commit. As reversões são consideradas a opção mais segura de desfazer devido a esse fluxo de trabalho de commit. A criação de commits de reversão deixam um rastro visível no histórico de commits de quando uma operação de desfazer foi executada.

Parabéns! Você terminou. Volte para este tutorial quando quiser ou veja a seção Como fazer alterações para se aprofundar mais. Continue fazendo um bom trabalho no Bitbucket!