Ouvimos dizer que hoje em dia, saber git é como saber inglês no mundo da programação, é indispensável. E de facto, todos os desenvolvedores dizem saber git até have rum problema minimamente mais complexo. Todos sabem fazer push, sabem clonar, sabem até gerir branches, e confiam (na minha opinião demasiado) no gestor de versões do Visual Studio Code.

Mas eu quero que as pessoas saibam git a sério, e este tutorial vem resolver as perguntas que quase ninguém sabe responder, aquelas que eu, ao ensinar, perguntava aos seniors, e davam uma resposta vaga, ou coisas do tipo rebase é o ato de fazer rebasing 😑.

A minha 🔥hot take🔥: Eu acredito vivamente que as pessoas devem usar o CLI em vez de qualquer outra interface. Quem interage com o repositório deve se sentir no completo controlo e perceção do que está a acontecer, e do que está a acontecer. E ainda mais, para resolver problemas complexos num repositório, utiliza-se sempre o CLI.

Vamos começar pelo início.

Conceitos Chave

Repositório (repo) 🌐🗄️

Um projeto gerido pelo git. Contém "history" e "branches".

Clone 💻🗄️

Leval o repositório online (remote) para o seu computador (local). Pode trabalhar no seu computador offline, e experimentar em total segurança.

Working Directory 💾

Os ficheiros que está a editar atualmente. Sempre que grava um ficheiro, boom - ele faz parte do Working Directory.

Staging Area 🎤

O palco que vai conter todas as coisinhas a incluir num commit. Permite que organizemos mudanças agrupadas por commit.

Commit 🎁

A snapshot + message explaining changes. Immutable once created Traceability: builds, deploys, and audits tie back to commits

Branch 🎋

A movable label pointing to a commit; evolves independently Safe experimentation: feature, fix, release branches

Remote 🌐

A shared repo hosted on a service (GitHub, GitLab) Team sync & CI triggers

Pull Request (PR) 🌲👈🎄 (🌐)

A request to merge changes from one branch into another, with discussion & review Enforces quality gates: review, tests, approvals

Merge 🌲👈🎄 (💻)

Combine histories; bring branch work into another branch Integrate features; ship value

Conflict 🎄💔🎄

Git can't auto-merge overlapping edits. Needs a human decision Happens in real collaboration—must be comfortable resolving

Tag / Release 🏷️

A named pointer to a specific commit (often versioned) Reproducible builds & deployments

---

Configuração do git

Git é o sistema de controlo de versões que vive no computador e gere o histórico do código.

Por norma (em 2026), o git vem instalado no Windows, no MacBook, e no Linux. Temos de configurar o CLI (Command Line Interface) do git para utilizar o git. Várias ferramentas visuais (como o GitHub Desktop) utilizam o CLI por trás da cortina.

Porque raios se chama CLI? - Command Line refere-se ao ambiente onde escrevemos comandos em linha (um por um), e “Interface” é simplesmente o meio através do qual interagimos com um programa. Um detalhe, pronuncia-se "ci él ai", e não "cli..." (que soa outra coisa 👀)

Ao fazer (numa linha de comandos):

git --version

Verificamos se o git está instalado, deve retornar a versão. Se apresentar erro, temos de fazer download.

Neste tutorial, vamos utilizar o GitHub, um provedor de serviços git que aloja repositórios online. Devem criar uma conta no GitHub para mais tarde trabalharmos nela. GitHub é um serviço online que usa git para guardar, partilhar e colaborar em repositórios na nuvem. Opcionalmente, podem instalar o GitHub Desktop, mas não iremos utilizá-lo neste tutorial.

Configurar a nossa conta localmente

Com git, podemos trabalhar 100% localmente, mas é bom armazernarmos as nossas coisas na Cloud para, caso o nosso computador queime, termos os resultados salvos.

Mas para subirmos o nosso código, precisamos das credenciais corretas. Inicialmente, vamos trabalhar com HTTPS para nos autenticarmos, e mais tarde abordamos a conexão SSH.

Vamos executar os seguintes códigos:

git config --global user.name "professordiogodev" # <- o vosso username
git config --global user.email "diogo@dionamite.com" # <- o vosso e-mail

Tem alunos que se esquecem do username/email utilizado. Acedam ao Perfil > Settings > Emails.

Agora, sempre que adicionarmos um pedaço de código ao nosso repositório (um commit), ele vai ter o autor e o e-mail junto com esse "commit".

Mas falta a autenticação. Nós vamos tratar desse passo mais tarde, quando estivermos a fazer um push.

---

Criar um Repositório

No canto superior direito,

• criar repo

E agora, temos de adicionar coisas no repositório.

O GitHub sugere que utilizemos os seguintes códigos para começar. Eu quero que saibamos tudo o que está a acontecer neste snippet:

echo "# reporissimo" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/professordiogodev/reporissimo.git
git push -u origin main

Vamos começar!

---

Antigamente (de 2022 para trás) no GitHub, utilizávamos senhas (password authentication) para nos autenticar e poder contribuir para repositórios. Mas para aumentar a segurança para todas as pessoas que utilizam o git, ele agora pede uma PAT (Personal Access Token), uma password temporária (portanto um token) gerada no próprio GitHub que permite dar autenticação à nossa máquina durante um período de tempo.

Essa PAT, quanto é gerada, é automaticamente apagada após sairmos da página. Isso é de propósito, para nunca mais ninguém ter acesso a ela.

Bora lá gerar essa PAT (eu sempre penso em patricinha ou pat em inglês que significa dar festinhas).

Vamos ao Perfil (canto superior direito) > Settings > Developer Settings (cá em baixo) > Personal Access Tokens > Tokens (classic) > Generate New Token > Generate New Token (classic)

1. Dão um nome. à token.
2. Colocam um tempo de expiração (por exemplo 60 dias)
3. Adicionam repo e workflow
4. Fazem scroll para baixo e fazem Generate New Token

(Em vez de patricinha, coloquem por exemplo main-token-dev)

É gerada uma token com este formato:

Aí vocês copiam, e jogam no terminal:

kkk

---

HTTPS vs ssh

Flow do Git Edit Code / IaC → Commit → Push to Remote → CI Pipeline Runs → Tests / Build / Package / Deploy

Áreas do git

Working Dir → Staging Area → Commit (Local History)

Working Directory: Where you edit files Staging Area: "Yes, include these changes in the next snapshot" Commit: Permanent, versioned snapshot with a message

Local Commits ↔ Push / Pull ↔ Remote (GitHub)

Os Commits

Conteúdos de um Commit

Branches

Branches como labels para um commit

Branch Naming Guidelines feature/

Workflow

This is the small, repeatable workflow we'll practice:

Clone the training repo from GitHub Create a feature branch named feature/your-feature Make a small change (add your name to a contributors file, or update a YAML value) Commit with a clear message Push your branch to GitHub Open a Pull Request to merge into main Request a review from a classmate Merge after approval Observe the CI pipeline run automatically

Merges

Merge Strategies Strategy When to Use Result Create a Merge Commit Default; preserves branch history One new merge commit joins histories Squash & Merge Clean up many small commits into one logical change Single commit on main. Good for noisy branches Rebase & Merge Advanced; linear history Your commits replayed on top of main

Merge Conflicts: What, Why, and How to Fix

Conflict = Git can't auto-decide which version of a file to keep because overlapping lines changed in two branches.

How You'll See It:

<<<<<<< HEAD
current branch version
=======
incoming branch version
>>>>>>> branch-name

Explain this code

Resolve in 4 Steps:

Open the conflicted file Decide what the final version should be (yours, theirs, or a combination) Remove the conflict markers and save Stage the resolved file and commit

Commit Hygiene for DevOps Teams

Do:

Use the imperative mood: "Add pipeline stage for integration tests" Reference work items: Fixes #42 auto-closes an issue on merge Group related changes: update YAML + pipeline param in same commit Avoid:

Drive-by formatting + feature + refactor in one commit "Stuff" / "update" commit messages Committing secrets or credentials (add them to .gitignore; use secrets managers)

Part 6: Git + CI/CD Integration

Git Events That Trigger Automation Git Event CI Use Case Push to branch Run lint, unit tests, build artifact Pull Request opened/updated Run integration tests; policy checks Tag pushed (e.g., v1.2.0) Build release image & deploy to staging/prod Merge to main Trigger full pipeline to production

Rebase

Rebase Interativo

Remover conteúdo antigo com o rebase interativo

Git Reset

Git Reset Soft

Git Reset Hard

Git Reset Mixed

Pull é um merge?

Stash