Tutorial Git: os comandos básicos (add, commit, push, pull)

Cinco comandos chegam para o trabalho do dia a dia: status, add, commit, push e pull. Este capítulo passa por cada um deles e aborda depois aquilo que nenhum tutorial devia saltar: como voltar atrás quando te enganas.

Um requisito prévio: a tua identidade tem de estar declarada, caso contrário o Git recusa o teu primeiro commit. Se ainda não o fizeste, volta ao capítulo de instalação.

As três zonas do Git

Tudo fica mais simples assim que percebes que os teus ficheiros estão sempre numa de três zonas.

• O diretório de trabalho: os teus ficheiros tal como os vês no explorador.
• O índice, também chamado staging area: a lista do que vai entrar no próximo commit. git add coloca lá as alterações.
• O repositório: o histórico dos commits, aquilo que git commit alimenta.

Esta zona intermédia baralha ao início, mas é ela que te permite registar três alterações em cinco e guardar as outras duas para um commit à parte.

git status, o comando que se escreve a toda a hora

Diz-te em que ponto estás e as suas mensagens contêm quase sempre o comando a escrever a seguir. Habitua-te a lançá-lo antes e depois de cada operação.

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.env
	app.js
	node_modules/

nothing added to commit but untracked files present (use "git add" to track)

A versão curta cabe numa linha por ficheiro e depressa se torna um reflexo:

git status --short

?? .env
?? app.js
?? node_modules/

?? assinala um ficheiro que o Git ainda não segue, A um ficheiro adicionado ao índice, M um ficheiro modificado.

.gitignore: o que nunca deve entrar no repositório

Antes mesmo do primeiro git add, põe de parte o que não tem nada que fazer num repositório: as dependências reinstaláveis, os ficheiros de configuração com segredos lá dentro, os ficheiros gerados pelo teu sistema ou pelo teu editor.

Cria um ficheiro .gitignore na raiz do projeto:

node_modules/
vendor/
.env
.env.local
dist/
build/
*.log
.DS_Store
.idea/
.vscode/

Volta a lançar o git status: os ficheiros ignorados desapareceram da lista.

?? .gitignore
?? app.js

O .gitignore, esse, é versionado: faz parte do projeto e deve ser partilhado com a equipa.

Atenção a uma armadilha: o .gitignore não tem qualquer efeito sobre um ficheiro já seguido. Se fizeste commit de um .env antes de te lembrares disso, tens de o retirar explicitamente do índice:

git rm --cached .env
git commit -m "Retire le fichier .env du suivi"

A opção --cached é essencial: retira o ficheiro do índice sem o apagar do teu disco.

E dá por comprometidos os segredos que ele continha: continuam legíveis no histórico. Muda-os.

git add: preparar o commit

git add app.js          # um ficheiro
git add src/            # uma pasta inteira
git add .               # tudo o que mudou dentro da pasta atual
git add -p              # escolher bloco a bloco, de forma interativa

O git add -p merece ser experimentado cedo. O Git mostra-te cada bloco de alterações e pergunta-te se o queres no commit. É a maneira mais simples de produzir commits que contam uma só coisa.

git commit: registar

git commit -m "Ajoute la page d'accueil"

[main (root-commit) fd4fdb7] Ajoute la page d accueil
 2 files changed, 3 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 app.js

Se não houver nada no índice, o Git não cria nada e diz-to:

On branch main

Initial commit

nothing to commit (create/copy files and use "git add" to track)

Sobre as mensagens de commit, só uma regra vale a pena reter: escreve o que o commit faz, não aquilo em que mexeste. «Corrige o cálculo do IVA nas encomendas fora da UE» vale mais do que «alteração fatura.php». Estás a escrever para ti próprio daqui a seis meses.

O atalho -am combina o add e o commit, mas apenas para os ficheiros já seguidos:

git commit -am "Corrige le libellé du bouton"

Ler o histórico

git log                                  # completo
git log --oneline                        # uma linha por commit
git log --oneline --graph --decorate     # com o desenho das branches
git log -p app.js                        # o histórico de um único ficheiro, com os diffs

* fd4fdb7 (HEAD -> main) Ajoute la page d accueil

HEAD designa o sítio onde te encontras no histórico. A seta indica que o HEAD segue a branch main.

Ver as alterações antes de fazer commit

Dois comandos, muitas vezes confundidos, que olham para duas zonas diferentes.

git diff            # o que mudou mas ainda não está no índice
git diff --staged   # o que está no índice e vai sair no próximo commit

diff --git a/app.js b/app.js
index e921523..ebde020 100644
--- a/app.js
+++ b/app.js
@@ -1 +1 @@
-console.log('hello');
+console.log('bonjour');

Depois de um git add app.js, a mesma alteração muda de lado: o git diff deixa de devolver seja o que for e o git diff --staged mostra o bloco. É a melhor forma de visualizar o índice.

git push e git pull: trocar com o servidor

git push        # enviar os commits locais
git pull        # trazer e integrar os dos outros

Estas duas formas curtas só funcionam se a branch tiver uma ligação ao servidor, estabelecida pelo -u do capítulo anterior. Para verificar essa ligação:

git branch -vv

* feature/panier bc2203a Page d accueil
  main           bc2203a [origin/main] Page d accueil

A branch main segue a origin/main, a branch feature/panier ainda não segue nada.

Se alguém fez push enquanto trabalhavas, o teu push é recusado. O que fazer e a explicação completa estão no capítulo sobre as branches.

Desfazer um disparate

É a parte que os principiantes mais procuram e a que menos lhes explicam. O bom reflexo é começar por responder a uma pergunta: aquilo que quero desfazer já foi para o servidor?

O ficheiro está modificado, quero voltar ao último commit

git restore app.js       # um ficheiro
git restore .            # todo o diretório de trabalho

Atenção, este comando destrói as tuas alterações sem rede: nunca chegaram a ser registadas em lado nenhum, o Git não as consegue recuperar.

Fiz git add depressa de mais

git restore --staged app.js

O ficheiro sai do índice, as tuas alterações ficam intactas no diretório de trabalho.

Estes dois comandos são o equivalente moderno de git checkout -- fichier e git reset HEAD fichier. O git restore existe desde o Git 2.23 e diz claramente o que faz, ao passo que o checkout e o reset fazem cada um três coisas diferentes conforme as opções.

A mensagem do meu último commit está má

git commit --amend -m "Le bon message"

O mesmo comando serve para acrescentar um ficheiro esquecido: faz o teu git add e volta a lançar o git commit --amend. Usa-o apenas num commit que ainda não tenha sido enviado: o --amend não modifica o commit, cria um novo no lugar dele, e o identificador antigo desaparece.

O commit já foi enviado, quero desfazê-lo como deve ser

git revert HEAD

[main 0246de1] Revert "Ajoute un fichier par erreur"
 1 file changed, 1 deletion(-)
 delete mode 100644 bug.txt

O git revert cria um novo commit que aplica o inverso do anterior. O histórico alonga-se em vez de ser reescrito, que é exatamente o que é preciso quando outras pessoas já receberam o teu trabalho. É o único método sem perigo numa branch partilhada.

O commit não foi enviado, quero apagá-lo

git reset --soft HEAD~1   # desfaz o commit e deixa tudo no índice
git reset --mixed HEAD~1  # desfaz o commit e mantém os ficheiros modificados (comportamento por omissão)
git reset --hard HEAD~1   # desfaz o commit e apaga as alterações

O --soft é o mais útil: devolve-te as alterações prontas para um novo commit, feito de outra maneira. O --hard é o único que destrói trabalho, e não avisa. Só o escrevas se tiveres a certeza.

Fiz um reset –hard a mais

Nem tudo está perdido. O Git guarda durante várias semanas o rasto de todos os estados por onde o HEAD passou:

git reflog

8207e54 HEAD@{0}: reset: moving to HEAD~2
f3951da HEAD@{1}: commit: Version 3
8ac671c HEAD@{2}: commit: Version 2
8207e54 HEAD@{3}: commit (initial): Version 1

Os dois commits apagados continuam lá. Localiza a linha do estado que queres, aponta o identificador e volta lá:

git reset --hard f3951da

O reflog, esse, só apanha o que tinha passado por um commit. Alterações que nunca foram registadas estão definitivamente perdidas, o que é mais um argumento para fazer commits com frequência.

O resumo

Já sabes trabalhar sozinho. O capítulo seguinte acrescenta os outros: branches, merges e conflitos. O último capítulo tratará depois da organização dessas branches à escala de uma equipa.