Explorando melhor os commits

Apresentação

Nesta seção iremos explorar um pouco mais o poder que os commits nos oferecem, incluindo boas práticas para fazer commits nos nossos arquivos e como “viajar” entre commits passados e presente. Este momento também servirá para ficarmos um pouco mais familiarizados com o uso do git através do terminal. Vamos utilizar o teminal visto que algumas coisas que faremos aqui não podem ser feitas através do RStudio.

Sempre ao fazer commits vale lembrar essas palavras:

Workflow para os commits

Em primeiro lugar sempre cheque se está tudo certo com seu repositório, se seu trabalho local está sincronizado com seu trabalho remoto. Para tanto pode digitar na linha de comando do terminal

git status

Se sua working tree estiver no status clean, quer dizer que você está sincronizada com o origin

Faça algumas modificações e depois vamos fazer a mesma sequencia de ações que fizemos anteriormente (stage, commit, push), mas agora usando a linha de comando. Para tanto podemos fazer assim

git add .
git commit -m "uma mensagem informativa"
git push

Pronto, fizemos a mesma coisa que anteriormente, mas agora utilizando o terminal :)

Amend

Lembra que muitos commits podem te deixar muito lento na escalada? E poucos commits podem ser pouco informativos caso queira reconstruir o que aconteceu com o repositório? Pois então, existe uma estratégia interessante para realizar commits, chamada de amend

Em um amend nós basicamente adicionamos um commit a um outro já existente. Por exemplo, imagine que fez apenas algumas poucas modificações de código que não necessitam necessariamente de um commit dedicada exclusivamente para tais, você pode fazer o seguinte:

1 - stage o arquivo que modificou

git add path/to/file

2 - faça um commit

git commit -m "WIP"

Note que coloquei WIP neste commit, por que? WIP é uma sigla usada comumente no versionamente para Working In Progress. Sempre que tiver um commit desse quer dizer que o commit que fez ainda está sendo trabalhado.

Ainda não faça o push. Faça mais algumas modificações, e, digamos que agora fez modificações relevantes no código que merecem um commit dedicado. Mas lembre-se que o último commit é um WIP. O que fazemos agora é um amend ao WIP

3 - faça um amend

git commit --amend -m "Aqui um commit com uma mensagem informativa, como sempre"
git push

Pronto, agora temos uma mensagem informativa que foi adicionada ao WIP e não precisamos fazer um push do passo intermediário (WIP), deixando nossa escalada mais rápida

Viajando entre commits

Uma das maiores potencialidades dos commits é a possibilidade que podemos navegar entre commits. Ou seja, podemos navegar entre estados distintos do nosso trabalho a medida que ele é desenvolvido. Podemos checar esse histórico tanto na nossa página do repositório no GitHub quanto usando o RStudio, como mostrado na imagem a seguir

Para tanto você precisa apenas abrir a aba do Git no RStudio, como vimos anteriormente, e clicar em History no canto superior esquerdo da janela de revisões. Tudo o que vemos são todos os commits que foram realizados desde que esse repositório foi formado pela primeira vez.

Elementos importantes do commit

Alguns elementos presentes no commit são importantes. O principal deles é a chave SHA-1. Esta se trata de um identificador único do commit. Com ela podemos viajar entre commits, ou referenciar um dado commit em uma discussão no github. Por exemplo, supondo que estamos trabalhando colaborativamente (como nesse site :)), e eu gostei particularmente mais da versão do site que está há alguns commits atrás. Uma opção é abrir uma Issue (veremos isso mais tarde), e referenciar esse número. Ou simplesmente dizer para meu colaborador “Hey dê uma olhada no commit número XXXXXX”. Na imagem abaixo está em destaque a chave SHA.

Você pode abrir o arquivo no estado em que ele se encontrava em um dado commit clicando no arquivo modificado naquele commit selecionado. Por exemplo, digamos que eu queira ver o arquivo chamado rmarkdown-basics deste site editado dia 02 de Agosto, só precisamos clicar no arquivo, como mostrado na imagem abaixo:

Back to the future: revertendo o trabalho do repositório e voltando

Existem situações que gostariamos de reverter não só um arquivo em específico, mas o estado inteiro de um repositório em um dado momento no tempo.

Por exemplo, digamos que você fez um push quando não deveria. Ou mudou muitos arquivos de uma só vez, o que tornaria bastante trabalhoso reverter arquivo por arquivo (ainda que possível, utilizando o método apresentado anteriormente). Nesta situação podemos reverter o nosso repositório para algum momento do tempo. Para fazer isso precisamos, primeiro, identificar o momento do tempo que gostaríamos de retornar. E como isso é possível? Utilizando os commits. Como dito anteriormente, os commits são momentos do seu repositório (mais um motivo para utilizar commits informativos).

Existem algumas formas de retornar ao passado, da mais radical para a menos radical:

Deletar tudo e clonar novamente o repositório

O método mais radical, mas útil quando não fazemos ideia do que está errado, consiste em:

1. salvar os arquivos em uma pasta temporária
2. deletar o diretório local
3. clonar novamente o repositório a partir do github

Isso irá, obviamente, retornar o seu repositório para o estado que ele se encontrava no último push realizado para o GitHub

Resetando

Resetar na linguagem do versionamento significa, basicamente, realizar um CTR + Z no seu repositório. Em termos mais técnicos do versionamento isso equivale a mover o HEAD para o último commit realizado. Esse movimento para o passado pode ser feito de duas formas.

1. Movendo para o passado mas mantendo o trabalho localmente

git reset --soft HEAD~1

2. Movendo para o passado e deletando o trabalho localmente

git reset --hard HEAD~1

O que quer dizer esta sintaxe? Basicamente estamos movendo nosso HEAD (último commit) um commit no passado (HEAD~1). Se quisermos nos mover para commits mais antigos, por exemplo, dois commits anteriores, apenas mudamos o número 1 para 2 após o ~.

Outra opção que tem sido minha escolha preferida é o uso do git reflog juntamente com o reset. Digite o seguinte no terminal

git reflog

Isso irá fazer com que apareça no seu terminal um histórico de todos os commits que foram feitos até o presente momento. A figura a seguir mostra esse histórico para o repositório deste site.

Com o reflog você pode usar o index do commit para navegar no tempo. O index é o número que aparece logo após o HEAD@{index}. Esse index pode ser utilizado em conjunto com a função reset que vimos anteriormente. Por exemplo, se eu quiser voltar para o commit número 11, devo usar o seguinte código

git reset --soft HEAD@{11}

Isso retornará 11 commits em relação ao commit atual. Você pode voltar ao commit atual usando a mesma sintaxe. Lembrando que o argumento --soft retorna para o estado desejado mas mantém os arquivos no seu diretório local.

NOTE: Acesse o site Oh Shit, Git!? para uma série de dicas muito úteis sobre erros comuns quando estamos usando o Git

Atividade

Explore um pouco os commits que realizaram. Abra a página do github e também através do Rstudio, veja as diferenças, as vantangens e desvantagens de cada uma das abordagens

Throwback Commit

Vamos supor que realizamos um commit errado, e agora queremos voltar ao commit anterior, mas sem perder o trabalho que fizemos nos arquivos. Para isso podemos usar a abordagem anterior, navegando entre os arquivos e selecionando o arquivo que queremos em um determinado estado, substituimos pelo arquivo atual e fazemos um novo commit. Esta opção pode ser a mais segura se estamos começando a mexer no versionamento. Outra opção é explorar as funções do git chamadas reset. As funções reset basicamente move o HEAD do seu diretório para um commit no passado. Esta abordagem pode causar algumas dores de cabeça no início, portanto recomendo usa-lá com cautela. Para mais informações sobre isso dê uma olhada nesse site.)