Git (1/3): controle de versões local

Aviso: Este post foi traduzido para o português usando um modelo de tradução automática. Por favor, me avise se encontrar algum erro.

📚 **Esta entrada faz parte da série _Guia de Git_**, dividida em três capítulos que se leem em ordem:

> * 👉 **Parte 1: Controle de versões local**

* Parte 2: Ramos

* Parte 3: Repositórios remotos, stash e tags

Introdução

Git é um software de controle de versões criado por Linus Torvalds, que o criou para poder ter um bom controle de versões quando desenvolveu o kernel do Linux.

As áreas do git

O Git tem três áreas, embora também se possa considerar uma quarta.

• A primeira é nosso espaço de trabalho, nele é onde temos todo o nosso código. Aqui, quando modificamos ou criamos um arquivo, ele passa a ficar como não rastreado, por isso temos que passá-lo para a área de staged
• A segunda área é a de staged. Aqui os arquivos que havíamos modificado ou criado e que não estavam *trackeados* passam a estar trackeados, ou seja, o Git passa a acompanhá-los. Aqui enviaremos os arquivos para a próxima área de head
• A terceira área é a de head. Nela gravamos uma versão do nosso código. Dessa forma, ao gravar versões, podemos voltar a versões anteriores se necessário. A versão gravada do nosso código pode ser enviada a um servidor de maneira que fique acessível para várias pessoas
• As três áreas anteriores correspondem ao trabalho local, mas há mais uma área, que é a de remote server. Aqui, o que fazemos é enviar a versão salva do nosso código para um servidor, de forma que tenhamos acesso ao código de qualquer lugar, ou que mais pessoas tenham acesso.

Para fazer uma analogia, é como um cenário em que você vai tirar uma foto. Primeiro você tem seus arquivos modificados, de forma que aqueles que quer imortalizar você envia para a área de staged, ou seja, para o cenário. No momento em que você enviou todos os arquivos que considera, você tira a foto, então envia todos os arquivos para a área de head. Dessa forma, você pode ir tirando muitas fotos, conforme o código vai evoluindo, de modo que você pode ter em um álbum de fotos a evolução do código. Por último, você pode enviar essa foto para um servidor para que fique acessível por mais pessoas, ou seja, você os envia para a área de remote server

Instalar git

Na maioria das distribuições Linux, o git já vem instalado, podemos verificá-lo executando git --version

Se você não o tiver ou quiser atualizar a versão do git, basta executar sudo apt update e, em seguida, sudo apt install git

Voltamos a verificar a versão

No meu caso, eu já tinha a última versão

Configuração inicial

Configuração do nome e do e-mail

Antes de começar a usar o git é conveniente que faças algumas configurações mínimas como o nome de usuário e o e-mail, esta informação é a que aparecerá na hora de mostrar quem fez alterações no código. Para fazer isto é preciso executar

git config --global user.name "<nome de usuário>"
git config --global user.email "<email>"

No meu caso, eu colocaria

git config --global user.name "MaximoFN"
git config --global user.email "maximofn@gmail.com

Como se pode ver, a flag --global o que faz é alterar a configuração global do git, mas se em um repositório específico você precisar definir outros dados, simplesmente navega até o repositório e remove a flag --global dos comandos anteriores

git config user.name "<nome de usuário>"
git config user.email "<email>"

Configurar o editor padrão

Quando mais adiante explicarmos o que são os commits, veremos que em uma das opções pode ser aberto um navegador para nós. Por padrão o git tentará usar vim, mas como não é um editor muito simples de usar, podemos modificá-lo. A seguir mostra-se como fazê-lo com alguns editores comuns

git config --global core.editor "code"  # vscode como editor
git config --global core.editor "atom"  # Atom como editor
git config --global core.editor "subl"  # Sublime Text como editor
git config --global core.editor "nano"  # Nano como editor

Verificar configuração de git

Para revisar a configuração do git podemos usar git config --list

Podemos usar os flags --global, --local e --system para ver apenas a configuração global, local (se existir) e de sistema (se existir)

No meu caso, não existe configuração de sistema

Se quiser saber apenas o valor de um parâmetro da configuração, bastaria introduzir git config <parameter>

Controle de versões de forma local

Inicializar um novo repositório (git init)

Há duas maneiras de inicializar um novo repositório fazendo

• Uma é fazendo git init . Isso criará uma nova pasta com o nome do repositório
• Outra é navegando até a pasta onde queremos criar um repositório e executando git init

Vou criar um novo repositório

Se agora fizermos ls, veremos que foi criada uma nova pasta chamada notebook_git

Nós nos mudamos para ela

Agora, dentro da pasta, temos duas maneiras de saber que o repositório foi criado: uma é fazendo ls -a, que mostrará todos os arquivos, e veremos que há uma pasta chamada .git. A outra maneira é fazendo git status, que nos dirá o estado do repositório

Como estamos em um notebook, cada célula tem seu path no path do notebook, por isso as duas vezes tive que fazer cd notebook_git &&, para que mude para a pasta com o repositório que acabamos de criar.

Se agora eu executar git status em outro path onde um repositório não tenha sido inicializado, isso nos dará um erro

Criar novos arquivos

No momento em que inicializamos um repositório, podemos começar a criar novos arquivos, então criamos um e vemos o que acontece

Se agora fizermos novamente git status, veremos que nos aparece

Como se pode ver, agora está nos dizendo que o arquivo hello.py não está sendo rastreado. Ou seja, precisamos adicionar hello.py à área de staged, que, lembremos, era como o cenário onde íamos colocar tudo aquilo que mais tarde iremos fotografar.

Desfazer a criação de um novo arquivo

Neste caso, como são arquivos que o git ainda não está rastreando, ou seja, que ainda não estão na área de staged, teríamos três maneiras de fazer isso

• Apagando-o simplesmente: Como o git ainda não rastreia o arquivo, poderíamos fazer rm hello.py e pronto
• Eliminando-o por meio de um comando do Git: Antes o apagamos com rm, mas é possível que você esteja em um sistema que não tenha o comando rm. Nesse caso, pode-se usar o comando do Git git rm hello.py* Por último, podemos usar git clean. Isso é útil, por exemplo, quando há muitos arquivos novos e, assim, em um único comando, eliminamos todos.

git clean

Se executarmos git clean sem argumentos, ele nos dará um erro

Ele está nos dizendo que é necessário adicionar um destes flags -n, -i ou -f. Além disso, vamos ver o flag -d

• -n (dry run): Nos dirá qué arquivos serão excluídos, mas não os excluirá
• -i: Nos perguntará por cada arquivo que será apagado* -f: Forçará a exclusão dos arquivos
• -d: Também apagará pastas

Vamos testar, primeiro fazemos git clean -n para saber quais arquivos seriam apagados

Agora fazemos git clean -f para que o apague, já que estamos de acordo em que o apague

Como vemos, ele apagou hello.py

Adicionar um arquivo à área de staging (git add)

Voltamos a criar um arquivo

Voltamos a fazer um git status para verificar que temos o arquivo

Vemos que temos o arquivo hola.py, mas o git não está fazendo seu acompanhamento. Além disso, vemos que ele nos ajuda e nos diz use "git add" para fazê-los acompanhar

A sintaxe é a seguinte git add <arquivo>, mas podemos fazê-lo de várias maneiras

• Se quisermos adicionar mais de um arquivo, podemos fazê-lo colocando todos os arquivos que queremos adicionar à área de staged, separados por um espaço: git add
• Se quisermos adicionar todos os arquivos de um mesmo formato, por exemplo, se quisermos adicionar todos os arquivos de Python, seria git add *.py
• Se quisermos adicionar todos os arquivos de uma pasta git add /
• Se quisermos adicionar todos os arquivos, temos três maneiras: git add --all, git add -A ou git add .

Vamos adicionar o novo arquivo criado

Fazemos um git status para ver o que aconteceu

Como vemos, ele nos diz que temos um novo arquivo ao qual está fazendo acompanhamento e que está pendente de ser confirmado hola.py

Remover um arquivo da área de staged (git reset)

No caso de adicionarmos um arquivo à área de staged e quisermos removê-lo, temos que usar git reset <arquivo>, vamos ver isso

Criamos e adicionamos à área de stage um novo arquivo

Fazemos git status para verificar que está na área de stage

Como vemos, estão hola.py e adios.py, então usamos git reset adios.py para tirá-lo da área de staging

Fazemos um git status para verificar que saiu

Podemos ver que adios.py já não tem acompanhamento por parte do git, ele o tirou da área de stage

Fazemos git clean -f para apagá-lo

Commit (git commit)

Se voltarmos ao símile em que dissemos que a área de staged era o cenário onde enviávamos os arquivos aos quais queríamos tirar a foto, agora é hora de tirar a foto para imortalizar o estado atual. Isso é fazer um commit

Dessa maneira, registra-se o estado atual do código; assim, com cada commit, terá-se um registro da evolução do código. Assim como com um álbum de fotos, com cada foto vamos tendo um registro da evolução do que colocamos no cenário.

Como na hora de fazer o commit a alteração do código está sendo registrada, o git não nos deixa fazer o commit se não fizermos um comentário mínimo. Portanto, há duas maneiras de fazer commit

• git commit dessa forma abrirá o editor que tenhamos definido na configuração do git. Se não tivermos configurado um editor padrão, será aberto vi. Se quisermos alterar a configuração do editor, podemos fazer, por exemplo, git config --global core.editor "code" ou git config core.editor "code" para definir o VSCode como editor padrão de forma global ou local.
• git commit -m "Mensagem de commit". Desta maneira, adicionamos a mensagem diretamente

Ao fazer o commit da primeira forma, podemos ter uma primeira linha que será o título do commit e várias linhas a mais onde se explica em mais detalhe. Se quisermos poder fazer isso com a flag -m, bastará adicionar várias flags -m seguidas: git commit -m "Título do commit" -m "Primeira linha explicando mais" -m "Segunda linha explicando mais"

Uma vez que fizemos o commit, isso guardará um registro da alteração do nosso repositório de forma local. Ainda não nos conectamos a um servidor remoto

Vamos testar fazer o commit

Fazemos um git status

Vemos que ele nos diz que não há nada de novo, temos todo o nosso repositório totalmente controlado

Commit ignorando add (git commit -a -m ou git commit -am)

No caso em que queiramos levar todos os arquivos que modificamos para a área de staged e depois fazer um commit, podemos fazer tudo isso em um único passo por meio de git commit -a -m "mensaje", git commit --all -m "mensaje" ou git commit -am "mensaje"

Nota: Isso só é válido se um arquivo for modificado. Se o arquivo for novo e o git não estiver a segui-lo, isso não é válido

Vamos ver um exemplo, vamos modificar hola.py

Vamos fazer um git status para nos certificarmos

Podemos ver que na própria ajuda do git já nos sugere usar git commit -a, então vamos fazê-lo

Vamos fazer novamente um git status

Não há nada para fazer commit, a alteração já foi commitada

Modificar um arquivo ao qual já havia sido feito commit

Como enquanto desenvolvemos estamos modificando arquivos, pode ser que em algum arquivo ao qual já tínhamos feito commit o modifiquemos. No nosso caso vamos adicionar uma linha a hola.py

Se fizermos git status, veremos que hola.py tem modificações

Ver alterações em um arquivo (git diff <arquivo>)

Pode ser que já estejamos há algum tempo desenvolvendo desde o último commit e não saibamos quais modificações fizemos; para isso usamos git diff <archivo> que nos dirá as mudanças que fizemos

Embora não seja muito intuitivo, podemos ver que adicionámos a última linha em hola.py

Desfazer modificações em um arquivo (git restore <arquivo>)

Se as alterações que fizemos não nos agradarem e quisermos removê-las, o que podemos fazer é git restore <arquivo>

Vamos ver o que aconteceu com um git status

Vemos que as alterações em hola.py foram descartadas desde o último commit

Histórico de alterações (git log)

Com o git podemos ver o histórico de todas as alterações que fomos commitando, para isso usamos git log. É como se fôssemos revisar nosso álbum de fotos

Podemos ver o histórico de alterações; é preciso lê-lo de baixo para cima.

Primeiro vemos o commit com a mensagem Primer commit, hola.py, podemos ver a data, o autor e o hash, que é seu identificador único

A seguir, vemos o segundo commit com a mensagem Segundo commit, hola.py, com sua data, autor e hash. Além disso, ele nos mostra onde está o HEAD e em qual ramo estamos

Se usarmos flags, podemos obter a informação de diferentes maneiras, mas, dependendo de quais flags usemos, uma opção pode ser mais conveniente. A seguir, são mostradas algumas flags úteis:

• git log --oneline: Mostra os commits em uma única linha, com o hash abreviado e a mensagem do commit.
• git log --graph: Mostra um gráfico de texto do histórico do repositório, incluindo ramificações e fusões.
• git log --decorate: Mostra as referências (branches, tags, HEAD, etc.) no log junto com o commit ao qual apontam.
• git log --author="": Filtra o histórico de commits para mostrar apenas aqueles realizados por um autor específico.
• git log --since="": Mostra os commits realizados desde uma data específica. Você pode usar diferentes formatos de data, como "1 week ago" ou "2023-01-01".
• git log --until="": Mostra os commits realizados até uma data específica.
• git log : Mostra os commits de um ramo específico.* git log ..: Mostra os commits que estão no intervalo entre dois commits específicos.
• git log --grep="": Busca nas mensagens de commit por uma palavra ou frase específica.
• git log -p: Mostra as diferenças (na forma de patch) introduzidas em cada commit.
• git log -n : Mostra os últimos números de commits. Por exemplo, git log -n 5 mostrará os últimos 5 commits.
• git log --stat: Mostra as estatísticas de alterações em arquivos para cada commit, como o número de linhas adicionadas e removidas.

Por exemplo, uma maneira confortável de ver o histórico é usar git log --graph --oneline --decorate

Podemos ver que em vez de nos dar o hash inteiro, nos dá apenas alguns números; isso acontece porque, por enquanto, o repositório tem tão pouca história que com esses poucos números é suficiente. Se quiséssemos voltar ao ponto anterior, em vez de introduzir o hash inteiro (7c448f69e30ab1b5783f5cf9ee3ae5bc362ecd4d), bastaria introduzir apenas 7c448f6.

Mais adiante falaremos sobre os branches, mas agora vamos ver o que é o HEAD

CABEÇALHO

Enquanto desenvolvíamos, conseguimos fazer alterações e commitá-las, ou seja, fomos preenchendo o álbum de fotos do nosso código. HEAD é a posição no álbum em que estamos.

Normalmente é a última posição de todos os commits.

Se queremos saber em que ponto estamos, podemos fazer isso com git rev-parse HEAD

Como se pode ver, o hash obtido coincide com o último obtido ao executar git log

Modificar um commit (git commit --amend)

Talvez queiramos modificar um commit, seja porque queremos alterar a mensagem, seja porque queremos adicionar mais arquivos ao commit, de modo que veremos os dois casos

Modificar a mensagem de commit

Se apenas quiser modificar a mensagem, o que temos que fazer é git commit --amend -m "Nueva mensagem", vejamos um exemplo, vamos a modificar hola.py

Fazemos um git status

De fato, vemos que hola.py tem modificações, de modo que fazemos um commit com essas modificações

Vamos ver o histórico de commits

**Oh não!** escrevemos commot em vez de commit, então vamos modificar a mensagem

Vamos ver o histórico

Vemos que agora está bem

Adicionar arquivos ao último commit

Suponha que tenhamos esquecido de adicionar um arquivo ao último commit; simplesmente fazemos um git add com esse arquivo e fazemos git commit --amend -m "mensaje"

Vamos criar dois novos arquivos

Agora fazemos commit apenas de um.

Como vemos, deixámos o ficheiro 2, de modo que modificamos o commit e adicionámos o ficheiro 2

Agora o último commit tem os dois novos arquivos

Desfazer um commit (git reset HEAD~1)

Com este comando dizemos ao git que retroceda uma posição no histórico de commits. Há duas opções --soft, que não apagarão as alterações que tenhamos feito, e --hard, que sim o fará.

Desfazer um commit mantendo as alterações (git reset --soft HEAD~1)

Vamos criar um novo arquivo

Fazemos um git status

Fazemos um commit adicionando este arquivo

Vemos que no último commit está archivo3.py, vamos eliminar o commit mantendo archivo3.py

Fazemos agora um git log para ver se o último commit foi eliminado

De fato, vemos que o último commit foi removido.

Fazemos um git status para ver se archivo3.py foi preservado

Foi mantido

Desfazer um commit descartando as alterações (git reset --hard HEAD~1)

Temos archivo3.py que criámos e o temos na área de stage

Portanto, fazemos um commit

Fazemos um git log para verificar que há um commit com este arquivo

De fato, há um commit adicionando arquivo3.py. Agora removemos esse commit descartando arquivo3.py

Fazemos um git log para verificar que o último commit foi eliminado

O commit com arquivo3.py foi eliminado, agora fazemos um git status para verificar o que aconteceu com arquivo3.py

Não aparece archivo3.py como um arquivo que precise ser commitado, vamos ver se realmente foi eliminado completamente

De fato, archivo3.py foi removido do sistema de arquivos

Modificar um commit remoto (git push --force)

Embora mais adiante veremos como sincronizar-nos com repositórios remotos, no caso de que tenhas feito um commit, o tenhas enviado para um repositório remoto (git push) e tenhas modificado o commit localmente (porque modificaste a mensagem ou desfizeste o commit), para reverter as alterações no repositório remoto tens de fazer git push --force

**Cuidado**: Este comando modifica o histórico do repositório remoto, por isso pode afetar o resto das pessoas que estejam trabalhando com esse repositório, então use este comando com muito cuidado e segurança. Vale mais a pena ter um histórico de commits, no qual primeiro está o commit em que você colocou a descrição errada e depois o novo commit com a nova descrição corretamente definida, do que ficar modificando o histórico.

Modificar um commit remoto (git push --force-with-lease)

Se você está convencido de alterar o histórico, pelo menos use git push --force-with-lease, que não modificará commits que tenham sido feitos posteriormente

Ignorar arquivos (.gitignore)

Suponha que temos um arquivo com API keys, esse arquivo na verdade não queremos que seja salvo no repositório, porque se depois compartilharmos esse repositório, qualquer pessoa teria acesso a essas chaves, por isso é preciso dizer ao git para não fazer o acompanhamento desse arquivo

Isto é feito com o arquivo .gitignore; nele, adiciona-se o caminho dos arquivos ou diretórios que não queremos que o Git acompanhe.

Vamos vê-lo

Criamos o arquivo com as chaves

Se fizermos git status, vemos que o Git o contempla

Se não fizermos nada, pode ser que um dia façamos um git add . e o incluamos no repositório, então, por segurança, precisamos dizer ao git que não siga este arquivo; para isso, o que fazemos é criar o .gitignore adicionando este arquivo

Vejamos o que acontece se agora fizermos git status

Vemos que o git deixou de levar em conta api_keys.py, mas leva em conta .gitignore, então fazemos um commit para adicionar .gitignore

Quais arquivos adicionar ao .gitignore?

• Arquivos que tenham credenciais ou chaves de API (você não deveria enviá-las ao repositório, simplesmente injetá-las por variáveis de ambiente)
• Pastas de configuração do seu editor (/.vscode)
• Arquivos de registro (log files)
• Arquivos de sistema como .DS_Store* Pastas geradas com arquivos estáticos ou compilações como /dist ou /build
• Dependências que podem ser baixadas (/node_modules)
• Cobertura de testes (/coverage)

Como ignorar sempre os mesmos arquivos?

Se, por exemplo, o seu IDE sempre gera os mesmos arquivos de configuração, seria bom poder dizer ao git que sempre ignore esses arquivos; para isso criamos um .gitignore global

No meu caso, vou adicionar o diretório __pycache__/

Agora é preciso indicar ao Git que esse é o nosso .gitignore global

Pronto, a partir de agora o diretório __pycache__/ sempre será ignorado

GitHub tem um repositório com .gitignores para muitas linguagens, eu me guiei por este para Python

Remover um arquivo de um commit

Vamos ver como eliminar um arquivo de um commit que fizemos. Primeiro criamos dois arquivos e fazemos commit deles

Fazemos um commit com os dois arquivos

A partir daqui, há duas opções para eliminar um arquivo de um commit:

• Excluir o arquivo e criar um novo commit* Desfazer o commit e criá-lo novamente sem o arquivo

Remover o arquivo e criar um novo commit

Suponha que queremos eliminar o arquivo archivo5.py, então o excluímos com git rm archivo5.py

Vamos fazer um git status para ver o que acontece

Como vemos, arquivo5.py foi apagado. Agora criamos um novo commit

Desfazer o commit e criá-lo novamente sem o arquivo

Voltamos a criar dois arquivos e fazer um commit

Primeiro desfazemos o último commit com git reset --soft HEAD~1

Fazemos um git status para ver o que aconteceu

Vemos que desfiz o commit, mas que os dois arquivos estão na área de staged, então para tirar do commit um dos arquivos, primeiro é preciso tirá-lo da área de staged; para isso fazemos git reset archivo6.py

Voltamos a fazer um git status

Vemos que arquivo7.py está na área de staged, enquanto arquivo6.py já não está. Agora podemos apagar o arquivo 6; para isso usamos git clean

Vamos executar novamente um git status

Como vemos archivo.py já não está, pelo que podemos fazer um novo commit

Removemos o último commit e o sobrescrevemos com um novo, eliminando o arquivo que queríamos

Histórico de alterações de um arquivo (git log <arquivo>)

Embora antes tenhamos visto como podíamos ver o histórico do repositório com git log, pode ser que não nos interesse o histórico de todo o repositório. Pode ser que tenhamos um bug em um arquivo de código que no início não tínhamos, por isso é possível que queiramos ver apenas o histórico desse arquivo; para isso usamos git log <arquivo>

Primeiro, vemos os arquivos que temos

Suponhamos que só queremos ver as mudanças em hola.py, então fazemos git log hola.py

Podemos ver que aparecem muitos menos resultados do que se tivéssemos feito git log

Ver modificações de um arquivo em um ponto específico do histórico (git show <hash> <arquivo> ou git diff <arquivo>)

Suponhamos que já sabemos em que ponto foi feita uma mudança no arquivo que contém um bug, então agora queremos saber quais mudanças foram realizadas para saber o que pode estar causando o bug; para isso podemos usar git show <hash> <archivo>

Vamos ver quais mudanças ocorreram em hola.py no hash c4930d7, ou seja, quando foi feito o terceiro commit

A maneira de ver as mudanças no git não é muito intuitiva, mas podemos ver que foi adicionada a linha print('Esta es la tercera línea')

Outra maneira de ver alterações é com git diff, temos duas opções, podemos ver as alterações do ficheiro no momento atual com um ponto concreto do histórico, para isso fazemos git diff <hash> <arquivo.

Por exemplo, se quisermos ver as mudanças de hola.py desde o primeiro commit (hash 1c95e4f) até a situação atual, devemos introduzir (git diff 1c95e4f hola.py)

Mas se o que queremos é ver a diferença entre um ponto concreto do histórico e outro ponto concreto, é preciso introduzir os hashes dos dois momentos, isto é git diff <hash1> <hash2> <archivo>

Se queremos ver as mudanças de hola.py entre o segundo commit (hash 6e99e73) e o primeiro commit (hash 1c95e4f) teríamos que introduzir git diff 1c95e4f 6e99e73 hola.py

O anterior nos mostra as mudanças do segundo commit em relação ao primeiro, mas se o que queremos são as mudanças do primeiro commit em relação ao segundo, basta colocar os hashes na ordem inversa de como os colocamos, ou seja git diff 6e99e73 1c95e4f hola.py

Viagem ao passado (git reset --hard <hash> ou git reset --soft <hash>)

Imaginemos que encontramos que todo lo que hicimos depois de gerar o bug não serve e temos que voltar a trabalhar desde ese ponto, podemos voltar a uma posição do histórico mediante git reset --hard <hash> (isto não manterá as alterações) ou git reset --soft <hash> (isto sim manterá as alterações)

Primeiro, vamos ver o histórico

Suponhamos que queremos ir ao momento em que fizemos o terceiro commit (hash c4930d7), além disso, fazemos isso sem manter as alterações, ou seja, todas as modificações que fizemos depois serão apagadas, fazemos git reset --hard c4930d7

Primeiro fazemos ls para ver os arquivos que temos agora

Vamos para o terceiro commit

Se fizermos ls veremos que já não temos nem archivo1.py, nem archivo2.py, nem archivo4.py, nem archivo7.py

De volta ao futuro (git reflog)

Suponhamos que nos arrependemos e queremos voltar ao ponto em que estávamos, ao último ponto no histórico, uma maneira seria fazer novamente git reset --hard <hash>. Mas imaginemos que não sabemos o hash, porque não fizemos git log antes e, se fizermos agora, ele só nos dará informação do histórico até o terceiro commit

Aqui o que podemos fazer é git reflog, que nos dará um histórico incluindo os saltos

Podemos ver que nos dice que estávamos no commit com hash 4bb9d75, isto é, o último commit que fizemos, e daí fomos até o commit com hash c4930d7, que, se você reparar, é o mesmo hash que o commit com a mensagem Tercer commit, hola.py. Portanto, já sabemos o hash do último commit, 4bb9d75, então para voltar à posição do último commit fazemos git reset --hard 4bb9d75

Se agora voltarmos a fazer um log

Vemos que, de fato, estamos na posição do último commit, *voltamos ao futuro*

Busca em arquivos (git grep <palavra>)

Se quisermos procurar em ficheiros, podemos fazê-lo com o comando git grep. Como o repositório que temos feito é muito pequeno e tem muito poucos ficheiros, vamos descarregar um novo através de um comando que veremos mais adiante em detalhe

O repositório que baixamos é o do código-fonte do SAM, uma rede neural da Meta para segmentar qualquer objeto. Entramos na pasta do repositório e buscamos, por exemplo, quantas vezes a palavra softmax foi escrita

Vemos que foi escrito nos arquivos segment_anything/modeling/image_encoder.py e segment_anything/modeling/transformer.py.

Se agora também queremos saber em quais linhas dos arquivos foi escrito, usamos o flag -n

Se o que queremos é contar quantas vezes a palavra aparece, podemos usar a flag -c

E vemos que aparece uma vez em cada arquivo

E nos diz que estão nas linhas 236 e 233, respectivamente

Busca em commits (git log -S <palavra>)

Se o que queremos é buscar no histórico de commits, podemos usar o comando git log -S <palabra>. Por exemplo, vamos buscar no histórico de commits do repositório que baixamos antes a palavra fix

Apagamos a pasta de SAM

---

➡️ **Continue na Parte 2: ramas**, onde aprenderás a trabalhar com várias linhas de desenvolvimento em paralelo.

Posts relacionados

• Git (2/3): ramos
• Git (3/3): repositórios remotos, stash e tags
• git-sim: Visualize Comandos Git