Reescrevendo a história do Git com confiança: um guia

Como desenvolvedor, você trabalha com Git o tempo todo. Você já chegou a um ponto em que disse: "Uh-oh, o que eu acabei de fazer?" Este post lhe dará as ferramentas para reescrever a história com confiança. Notas antes de começar Eu também dei uma palestra ao vivo cobrindo o conteúdo deste post. Se você preferir um vídeo (ou deseja assisti-lo junto com a leitura) — você pode encontrá-lo . aqui Estou trabalhando em um livro sobre Git! Você está interessado em ler as versões iniciais e fornecer feedback? Envie-me um e-mail: gitting.things@gmail.com Gravando alterações no Git Antes de entender como as coisas no Git, você deve primeiro entender como as alterações no Git. Se você já conhece todos os termos, sinta-se à vontade para pular esta parte. desfazer registramos É muito útil pensar no Git como um sistema para gravar instantâneos de um sistema de arquivos no tempo. Considerando um repositório Git, ele possui três “estados” ou “árvores”: Normalmente, quando trabalhamos em nosso código-fonte, trabalhamos a partir de um . Um (ou ) é qualquer diretório em nosso sistema de arquivos que tenha um associado a ele. diretório de trabalho diretório de trabalho (ectrory) árvore de trabalho repositório Ele contém as pastas e arquivos do nosso projeto e também um diretório chamado . Descrevi o conteúdo da pasta com mais detalhes em . .git .git uma postagem anterior Depois de fazer algumas alterações, você pode querer gravá-las em seu . Um (resumindo: ) é uma coleção de , cada um dos quais é um arquivo de como era a do projeto em uma data passada, seja na sua máquina ou na de outra pessoa. repositório repositório repo commits árvore de trabalho Um também inclui outras coisas além de nossos arquivos de código, como , branches, etc. repositório HEAD No meio, temos o ou a ; esses dois termos são intercambiáveis. Quando uma ramificação, o Git preenche o com todo o conteúdo do arquivo que foi verificado pela última vez em nosso e como eles se pareciam quando foram originalmente verificados. índice área de preparação checkout índice diretório de trabalho Quando usamos , o é criado com base no estado do . git commit commit índice Assim, o ou a é o seu playground para o próximo commit. Você pode trabalhar e fazer o que quiser com o , adicionar arquivos a ele, remover coisas dele e, somente quando estiver pronto, vá em frente e se comprometa com o repositório. índice, área de preparação, índice Hora de colocar a mão na massa 🙌🏻 Use para inicializar um novo repositório. Escreva algum texto em um arquivo chamado : git init 1.txt Dos três estados de árvore descritos acima, onde está agora? 1.txt Na árvore de trabalho, como ainda não foi introduzido no índice. Para lo, para adicioná-lo ao índice, use . organizá- git add 1.txt Agora, podemos usar para confirmar nossas alterações no repositório. git commit Você criou um novo objeto commit, que inclui um ponteiro para uma árvore que descreve toda a árvore de trabalho. Neste caso, será apenas dentro da pasta raiz. Além de um ponteiro para a árvore, o objeto commit inclui metadados, como carimbos de data/hora e informações do autor. 1.txt Para obter mais informações sobre os objetos no Git (como commits e árvores), . confira meu post anterior (Sim, “check-out”, trocadilho intencional 😇) O Git também nos informa o valor SHA-1 desse objeto de confirmação. No meu caso, foi (que são apenas os 7 primeiros caracteres do valor SHA-1, para economizar espaço). c49f4ba Se você executar este comando em sua máquina, obterá um valor SHA-1 diferente, pois é um autor diferente; além disso, você criaria o commit em um carimbo de data/hora diferente. Quando inicializamos o repositório, o Git cria uma nova ramificação (chamada por padrão). E . Portanto, por padrão, você tem apenas a ramificação . O que acontece se você tiver várias filiais? Como o Git sabe qual branch é o branch ativo? main uma ramificação no Git é apenas uma referência nomeada para um commit main O Git tem outro ponteiro chamado , que aponta (geralmente) para um branch, que então aponta para um commit. Por falar nisso, Inclui o nome da filial com alguns prefixos. HEAD sob o capô, HEAD é apenas um arquivo. Hora de introduzir mais mudanças no repositório! Agora, quero criar outro. Então, vamos criar um novo arquivo e adicioná-lo ao índice, como antes: Agora, é hora de usar . É importante ressaltar que faz coisas: git commit git commit duas Primeiro, ele cria um objeto commit, então há um objeto dentro do banco de dados interno do Git com um valor SHA-1 correspondente. Este novo objeto commit também aponta para o commit pai. Esse é o commit para o qual estava apontando quando você escreveu o comando . HEAD git commit Em segundo lugar, move o ponteiro do branch ativo — em nosso caso, seria , para apontar para o objeto commit recém-criado. git commit main Desfazendo as Alterações Para reescrever a história, vamos começar desfazendo o processo de introdução de um commit. Para isso, vamos conhecer o comando , uma ferramenta superpoderosa. git reset git reset --soft Portanto, o último passo que você fez antes foi , o que na verdade significa duas coisas — Git criou um objeto commit e moveu , o branch ativo. Para desfazer esta etapa, use o comando . git commit main git reset --soft HEAD~1 A sintaxe refere-se ao primeiro pai de . Se eu tivesse mais de um commit no grafo de commit, diga “Commit 3” apontando para “Commit 2”, que por sua vez está apontando para “Commit 1”. HEAD~1 HEAD E diga que estava apontando para “Commit 3”. Você poderia usar para se referir a “Commit 2”, e se referiria a “Commit 1”. HEAD HEAD~1 HEAD~2 Então, de volta ao comando: git reset --soft HEAD~1 Este comando pede ao Git para alterar qualquer que esteja apontando. (Nota: Nos diagramas abaixo, eu uso para “qualquer coisa que esteja apontando”). Em nosso exemplo, está apontando para . Portanto, o Git apenas mudará o ponteiro de para apontar para . Ou seja, apontará para “Commit 1”. HEAD *HEAD HEAD HEAD main main HEAD~1 main No entanto, esse comando afetou o estado do índice ou da árvore de trabalho. Portanto, se você usar , verá que está preparado, assim como antes de executar . não git status 2.txt git commit E o Ele começará em , vá para e depois para “Commit 1”. Observe que isso significa que “Commit 2” não está mais acessível em nosso histórico. git log? HEAD main Isso significa que o objeto de confirmação de “Commit 2” foi excluído? 🤔 Não, não foi deletado. Ele ainda reside no banco de dados interno de objetos do Git. Se você enviar o histórico atual agora, usando , o Git não enviará “Commit 2” para o servidor remoto, mas o objeto commit ainda existe em sua cópia local do repositório. git push Agora, faça commit novamente — e use a mensagem de commit de “Commit 2.1” para diferenciar esse novo objeto do “Commit 2” original: Por que “Commit 2” e “Commit 2.1” são diferentes? Mesmo se usássemos a mesma mensagem de commit, e mesmo que eles apontem para (da pasta raiz composta por e ), eles ainda possuem timestamps diferentes, pois foram criados em momentos diferentes. o mesmo objeto árvore 1.txt 2.txt No desenho acima, mantive o “Commit 2” para lembrar que ele ainda existe no banco de dados de objetos internos do Git. Ambos “Commit 2” e “Commit 2.1” agora apontam para “Commit 1”, mas apenas “Commit 2.1” é acessível a partir . HEAD Git Reset --Misto É hora de voltar ainda mais e desfazer ainda mais. Desta vez, use (observação: é a opção padrão para ). git reset --mixed HEAD~1 --mixed git reset Este comando começa da mesma forma que . O que significa que ele pega o ponteiro de qualquer que esteja apontando agora, que é o branch , e o define como , em nosso exemplo — “Commit 1”. git reset --soft HEAD~1 HEAD main HEAD~1 Em seguida, o Git vai além, desfazendo efetivamente as alterações que fizemos no índice. Ou seja, alterando o índice para que coincida com o atual, o novo após defini-lo na primeira etapa. HEAD HEAD Se executarmos , isso significa que seria definido como (“Commit 1”) e, em seguida, Git corresponderia o índice ao estado de “Commit 1” — nesse caso, significa que não fará mais parte do índice. git reset --mixed HEAD~1 HEAD HEAD~1 2.txt É hora de criar um novo commit com o estado do original “Commit 2”. Desta vez, precisamos preparar novamente antes de criá-lo: 2.txt Git Reset --Hard Vá em frente, desfaça ainda mais! Vá em frente e execute git reset --hard HEAD~1 Novamente, o Git começa com o estágio , configurando qualquer para o qual esteja apontando ( ), para (“Commit 1”). --soft HEAD main HEAD~1 Até agora tudo bem. Em seguida, passando para o estágio , combinando o índice com . Ou seja, o Git desfaz a preparação de . --mixed HEAD 2.txt É hora da etapa onde o Git vai ainda mais longe e combina o diretório de trabalho com o estágio do índice. Neste caso, significa remover também do diretório de trabalho. --hard 2.txt (**Observação: neste caso específico, o arquivo não foi portanto não será excluído do sistema de arquivos; não é realmente importante para entender ). rastreado, git reset Portanto, para introduzir uma alteração no Git, você tem três etapas. Você altera o diretório de trabalho, o índice ou a área de preparação e, em seguida, confirma um novo instantâneo com essas alterações. Para essas alterações: desfazer Se usarmos , desfazemos a etapa de confirmação. git reset --soft Se usarmos , também desfazemos a etapa de preparação. git reset --mixed Se usarmos , desfazemos as alterações no diretório de trabalho. git reset --hard Cenários da vida real! Cenário 1 Então, em um cenário da vida real, escreva “Eu amo o Git” em um arquivo ( ), pois todos nós amamos o Git 😍. Vá em frente, stage e confirme isso também: love.txt Opa! Na verdade, eu não queria que você o cometesse. O que eu realmente queria que você fizesse era escrever mais algumas palavras de amor neste arquivo antes de enviá-lo. O que você pode fazer? Bem, uma maneira de superar isso seria usar , desfazendo efetivamente as ações de commit e staging que você realizou: git reset --mixed HEAD~1 Portanto, aponta para “Commit 1” novamente e não faz mais parte do índice. No entanto, o arquivo permanece no diretório de trabalho. Agora você pode ir em frente e adicionar mais conteúdo a ele: main love.txt Vá em frente, prepare e confirme seu arquivo: Muito bem 👏🏻 Você tem esse histórico claro e agradável de “Commit 2.4” apontando para “Commit 1”. Agora temos uma nova ferramenta em nossa caixa de ferramentas, 💪🏻 git reset Essa ferramenta é super, super útil e você pode realizar quase tudo com ela. Nem sempre é a ferramenta mais conveniente de usar, mas é capaz de resolver quase todos os cenários de reescrita da história se você usá-la com cuidado. Para iniciantes, recomendo usar apenas para quase todas as vezes que você quiser desfazer no Git. Depois de se sentir confortável com isso, é hora de passar para outras ferramentas. git reset Cenário #2 Consideremos outro caso. Crie um novo arquivo chamado ; palco e cometer: new.txt Ops. Na verdade, isso é um erro. Você estava em e eu queria que você criasse este commit em um branch de recursos. meu mal 😇 main Existem duas ferramentas mais importantes que eu quero que você tire deste post. O é . A primeira e muito mais importante é o estado atual versus o estado em que você deseja estar. segundo git reset colocar no quadro branco Para este cenário, o estado atual e o estado desejado têm a seguinte aparência: Você notará três mudanças: aponta para “Commit 3” (o azul) no estado atual, mas para “Commit 2.4” no estado desejado. main A ramificação não existe no estado atual, mas existe e aponta para “Commit 3” no estado desejado. feature aponta para o no estado atual e para no estado desejado. HEAD main feature Se você pode desenhar isso e sabe como usar , você pode definitivamente sair dessa situação. git reset Então, novamente, é respirar e extrair isso. a coisa mais importante Observando o desenho acima, como passamos do estado atual ao desejado? Claro que existem algumas formas diferentes, mas vou apresentar apenas uma opção para cada cenário. Sinta-se à vontade para brincar com outras opções também. Você pode começar usando . Isso definiria para apontar para o commit anterior, “Commit 2.4”: git reset --soft HEAD~1 main Olhando novamente para o diagrama atual versus desejado, você pode ver que precisa de um novo branch, certo? Você pode usar para ele ou (que faz a mesma coisa): git switch -c feature git checkout -b feature Este comando também atualiza para apontar para a nova ramificação. HEAD Como você usou , você não alterou o índice, então ele tem exatamente o estado que você deseja confirmar - que conveniente! Você pode simplesmente se comprometer com o ramo : git reset --soft feature E você chegou ao estado desejado 🎉 Cenário #3 Pronto para aplicar seu conhecimento a casos adicionais? Adicione algumas alterações a e também crie um novo arquivo chamado . Organize-os e comprometa-se: love.txt cool.txt Oh, opa, na verdade eu queria que você criasse dois commits separados, um para cada mudança 🤦🏻 Quer experimentar este você mesmo? Você pode desfazer as etapas de commit e staging: Após esse comando, o índice não inclui mais essas duas alterações, mas ambas ainda estão em seu sistema de arquivos. Portanto, agora, se você apenas colocar em stage , poderá confirmá-lo separadamente e, em seguida, fazer o mesmo para : love.txt cool.txt Legal 😎 Cenário #4 Crie um novo arquivo ( ) com algum texto e adicione algum texto a . Organize ambas as alterações e confirme-as: new_file.txt love.txt Opa 🙈🙈 Então, desta vez, eu queria que fosse em outro branch, mas não em um branch, mas em um branch já existente. novo Então o que você pode fazer? Vou te dar uma dica. A resposta é muito curta e muito fácil. O que fazemos primeiro? Não, não . Nos desenhamos. Essa é a primeira coisa a fazer, pois tornaria tudo muito mais fácil. Então este é o estado atual: reset E o estado desejado? Como você sai do estado atual para o estado desejado, o que seria mais fácil? Então, uma maneira seria usar como você fez antes, mas há outra maneira que eu gostaria que você tentasse. git reset Primeiro, mova para apontar para a ramificação : HEAD existing Intuitivamente, o que você quer fazer é pegar as alterações introduzidas no commit azul e aplicá-las (“copiar e colar”) no topo da ramificação . E o Git tem uma ferramenta só para isso. existing Para pedir ao Git para fazer as alterações introduzidas entre este commit e seu commit pai e apenas aplicar essas alterações no branch ativo, você pode usar . Este comando pega as mudanças introduzidas na revisão especificada e as aplica ao commit ativo. git cherry-pick Ele também cria um novo objeto commit e atualiza a ramificação ativa para apontar para esse novo objeto. No exemplo acima, eu especifiquei o identificador SHA-1 do commit criado, mas você também pode usar , já que o commit cujas alterações estamos aplicando é aquele para o qual está apontando. git cherry-pick main main Mas não queremos que essas alterações existam no ramo . apenas aplicou as alterações ao branch . Como você pode removê-los do ? main git cherry-pick existing main Uma maneira seria para e, em seguida, usar : switch main git reset --hard HEAD~1 Você fez isso! 💪🏻 Observe que realmente calcula a diferença entre o commit especificado e seu pai e, em seguida, aplica-os ao commit ativo. Isso significa que, às vezes, o Git não conseguirá aplicar essas alterações, pois pode ocorrer um conflito, mas isso é assunto para outro post. git cherry-pick Além disso, observe que você pode pedir ao Git para as alterações introduzidas em qualquer commit, não apenas nos commits referenciados por um branch. cherry-pick Adquirimos uma nova ferramenta, então temos e em nosso currículo. git reset git cherry-pick Cenário #5 Ok, então outro dia, outro repo, outro problema. Crie um commit: E -o para o servidor remoto: push Hum, opa 😓… Acabei de notar uma coisa. Há um erro de digitação aí. Eu escrevi em vez de . Opa. Então, qual é o grande problema agora? Eu ed, o que significa que outra pessoa já pode ter essas alterações. This is more tezt This is more text push pull Se eu substituir essas alterações usando , como fizemos até agora, teremos histórias diferentes e o inferno pode explodir. Você pode reescrever sua própria cópia do repositório o quanto quiser até que você o . git reset push Depois de a alteração, você precisa ter de que ninguém mais buscou essas alterações se for reescrever o histórico. push certeza Como alternativa, você pode usar outra ferramenta chamada . Este comando pega o commit que você está fornecendo e calcula o Diff de seu commit pai, assim como , mas desta vez, ele calcula as alterações inversas. git revert git cherry-pick Portanto, se no commit especificado você adicionar uma linha, o inverso excluirá a linha e vice-versa. criou um novo objeto commit, o que significa que é uma adição ao histórico. Ao usar , você não reescreveu o histórico. Você admitiu seu erro passado, e este commit é um reconhecimento de que você cometeu um erro e agora o corrigiu. git revert git revert Alguns diriam que é a forma mais madura. Alguns diriam que não é um histórico tão limpo quanto você obteria se usasse para reescrever o commit anterior. Mas esta é uma forma de evitar reescrever a história. git reset Agora você pode corrigir o erro de digitação e confirmar novamente: Sua caixa de ferramentas agora está carregada com uma nova ferramenta brilhante, : revert Cenário #6 Faça algum trabalho, escreva algum código e adicione-o a . Organize esta alteração e confirme-a: love.txt Fiz o mesmo na minha máquina e usei a tecla de seta no teclado para rolar de volta para os comandos anteriores e, em seguida, pressionei e… Uau. Up Enter Opa. Acabei de usar ? 😨 git reset --hard O que aconteceu? Git moveu o ponteiro para , então o último commit, com todo o meu trabalho, não pode ser acessado a partir do histórico atual. O Git também removeu todas as alterações da área de teste e, em seguida, combinou o diretório de trabalho com o estado da área de teste. realmente HEAD~1 precioso Ou seja, tudo condiz com esse estado onde meu trabalho está... desaparecido. Hora de surtar. Pirando. Mas, realmente, há uma razão para surtar? Na verdade não... Somos pessoas relaxadas. O que nós fazemos? Bem, intuitivamente, o commit acabou? Não porque não? Ele ainda existe dentro do banco de dados interno do Git. realmente Se eu soubesse onde fica, saberia o valor SHA-1 que identifica esse commit, poderíamos restaurá-lo. Eu poderia até desfazer o desfazer e para este commit. reset Portanto, a única coisa que realmente preciso aqui é o SHA-1 do commit “excluído”. Então a pergunta é, como faço para encontrá-lo? seria útil? git log Bem, na verdade não. iria para , que aponta para , que aponta para o commit pai do commit que estamos procurando. Em seguida, rastrearia a cadeia pai, que não inclui o commit com meu precioso trabalho. git log HEAD main git log Felizmente, as pessoas muito inteligentes que criaram o Git também criaram um plano de backup para nós, chamado de . reflog Enquanto você trabalha com o Git, sempre que você altera , o que pode ser feito usando , mas também outros comandos como ou , o Git adiciona uma entrada ao . HEAD git reset git switch git checkout reflog Encontramos nosso commit! É aquele que começa com . 0fb929e Também podemos nos relacionar com ele por seu “apelido” — . Assim como Git usa para chegar ao primeiro pai de , e para se referir ao segundo pai de e assim por diante, Git usa para se referir ao primeiro reflog pai de , onde apontou na etapa anterior. HEAD@{1} HEAD~1 HEAD HEAD~2 HEAD HEAD@{1} HEAD HEAD Também podemos pedir para nos mostrar seu valor: git rev-parse Outra maneira de visualizar o é usando , que pede para realmente considerar o : reflog git log -g git log reflog Vemos acima que o , assim como , aponta para , que aponta para “Commit 2”. Mas o pai dessa entrada no aponta para “Commit 3”. reflog HEAD main reflog Então, para voltar ao “Commit 3”, você pode simplesmente usar (ou o valor SHA-1 de “Commit 3”): git reset --hard HEAD@{1} E agora, se : git log Nós salvamos o dia! 🎉👏🏻 O que aconteceria se eu usasse esse comando novamente? E executou ? Git definiria para onde estava apontando antes da última , significando “Commit 2”. Podemos continuar o dia todo: git commit --reset HEAD@{1} HEAD HEAD reset Olhando para nossa caixa de ferramentas agora, ela está repleta de ferramentas que podem ajudá-lo a resolver muitos casos em que as coisas dão errado no Git: Com essas ferramentas, agora você entende melhor como o Git funciona. Existem mais ferramentas que permitem reescrever o histórico especificamente, ), mas você já aprendeu muito neste post. Em postagens futuras, vou mergulhar no também. git rebase git rebase A ferramenta mais importante, ainda mais importante do que as cinco ferramentas listadas nesta caixa de ferramentas, é colocar no quadro branco a situação atual versus a desejada. Acredite em mim, isso fará com que cada situação pareça menos assustadora e a solução mais clara. Saiba mais sobre Git Eu também dei uma palestra ao vivo cobrindo o conteúdo deste post. Se você preferir um vídeo (ou deseja assisti-lo junto com a leitura) — você pode encontrá-lo . aqui Em geral, cobre muitos aspectos do Git e seus componentes internos; você é bem-vindo (trocadilho intencional 😇) meu canal do youtube Confira Sobre o autor é o CTO e co-fundador da , uma ferramenta de desenvolvimento que ajuda os desenvolvedores e suas equipes a gerenciar o conhecimento sobre sua base de código com documentação interna atualizada. Omer é o fundador da Check Point Security Academy e foi o líder de segurança cibernética da ITC, uma organização educacional que treina profissionais talentosos para desenvolver carreiras em tecnologia. Omer Rosenbaum nadar Omer tem mestrado em Linguística pela Universidade de Tel Aviv e é o criador do . Breve canal do YouTube Publicado pela primeira vez aqui