Partilhar: WhatsApp
aulify · Sebenta
UC · Unidade de Competência · UC00617

UC00617 · Git e GitHub

Controlo de versões, branching, GitHub, workflow profissional
25h · 2.25 pontos crédito Curso: T. Desenv. Software ↗ Referencial oficial SNQ
Índice

Introdução

Git é o sistema de controlo de versões mais usado no mundo. Criado por Linus Torvalds em 2005, é hoje standard de facto para qualquer projecto de software (e cada vez mais para projectos não-software também).

GitHub é a plataforma cloud mais popular para hospedar repositórios Git, com mais de 100 milhões de developers.

Esta UC (25h) cobre os fundamentos do Git, uso do GitHub, e workflows profissionais que qualquer developer deve dominar.

Dominar Git = pré-requisito para qualquer função em desenvolvimento de software.

1. Controlo de versões

1.1 O problema sem Git

Cenário típico sem controlo de versões:

/projecto/
  projecto.html
  projecto_v2.html
  projecto_v3.html
  projecto_v3_FINAL.html
  projecto_v3_FINAL_v2.html
  projecto_FINAL_FINAL.html
  projecto_NOVO_FINAL.html
  projecto_FINAL_REAL.html
  projecto_a_usar_este.html  ← qual?

Problemas: - Que versão é a actual? - O que mudou entre versões? - Como combinar trabalho de 2 pessoas? - E se eu apagar a errada? - Como voltar atrás se algo correr mal?

1.2 Solução: controlo de versões

Version Control System (VCS) = sistema que regista cada mudança no código ao longo do tempo.

Tipos:

Centralizado (CVS, SVN — antigos): - Servidor central com todo o histórico. - Developers fazem checkout / commit. - Problema: offline não funciona; servidor down = parado.

Distribuído (Git, Mercurial — modernos): - Cada developer tem cópia completa do histórico. - Trabalha offline. - Sincroniza com servidor quando quiser. - Mais resiliente.

1.3 Por que Git?

1.4 Terminologia essencial

2. Git fundamentos

2.1 Instalação

Windows: download em git-scm.com → Git for Windows (inclui Git Bash).

Mac: 

brew install git

(ou já vem com Xcode Command Line Tools).

Linux:

sudo apt install git    # Debian/Ubuntu
sudo dnf install git    # Fedora

Verificar:

git --version

2.2 Setup inicial (uma vez apenas)

# Configurar nome e email (aparecem em commits)
git config --global user.name "Teu Nome Completo"
git config --global user.email "teu.email@example.com"

# Configurar editor padrão (opcional)
git config --global core.editor "code --wait"  # VSCode
git config --global core.editor "vim"          # Vim

# Configurar branch principal (moderno)
git config --global init.defaultBranch main

# Configurar cores
git config --global color.ui auto

# Verificar configurações
git config --list

2.3 Iniciar um repositório

Em projecto novo:

mkdir meu-projecto
cd meu-projecto
git init

Cria pasta .git/ (escondida) com toda a estrutura do Git.

Clonar projecto existente:

git clone https://github.com/utilizador/repo.git
cd repo

2.4 Estado dos ficheiros

git status

Mostra: - Untracked: ficheiros novos não conhecidos pelo Git. - Modified: ficheiros alterados desde último commit. - Staged: ficheiros preparados para commit.

2.5 Adicionar ao staging

# Adicionar ficheiro específico
git add ficheiro.txt

# Adicionar múltiplos
git add ficheiro1.txt ficheiro2.txt

# Adicionar tudo (na directoria actual e sub-pastas)
git add .

# Adicionar tudo no repo inteiro
git add -A

# Add interactivo (escolher hunks)
git add -p ficheiro.txt

2.6 Commit

# Commit com mensagem
git commit -m "Add login page"

# Commit detalhado (abre editor)
git commit

# Add + commit em um (apenas ficheiros tracked)
git commit -am "Update README"

# Modificar último commit (não publicado)
git commit --amend

2.7 Ver histórico

# Histórico completo
git log

# Compacto
git log --oneline

# Com diff
git log -p

# Gráfico
git log --graph --oneline --all

# Stats
git log --stat

# Filtrar
git log --author="João"
git log --since="2026-01-01"
git log --grep="bug"

2.8 Ver diferenças

# Working directory vs último commit
git diff

# Staged vs último commit
git diff --staged

# Entre dois commits
git diff abc123 def456

# De uma branch para outra
git diff main feature/x

2.9 Desfazer mudanças

# Descartar mudanças (working dir)
git checkout -- ficheiro.txt
# ou (Git moderno)
git restore ficheiro.txt

# Remover do staging (manter mudanças)
git reset HEAD ficheiro.txt
# ou
git restore --staged ficheiro.txt

# Desfazer último commit (manter mudanças)
git reset --soft HEAD~1

# Desfazer último commit (perder mudanças) ⚠️
git reset --hard HEAD~1

# Reverter commit (criar novo commit que desfaz)
git revert abc123

Diferença: - reset: reescreve histórico (perigoso se já published). - revert: cria novo commit (seguro).

2.10 .gitignore

Ficheiros que não queres versionar:

# .gitignore

# Dependências
node_modules/
__pycache__/
venv/
.venv/

# Build outputs
dist/
build/
*.pyc
*.class
*.o

# Editor / IDE
.vscode/
.idea/
.DS_Store
Thumbs.db
*.swp

# Logs
*.log
logs/

# Configurações sensíveis ⚠️
.env
.env.local
*.key
*.pem
secrets.json

# OS
.DS_Store
desktop.ini

Sempre commit .gitignore logo no primeiro commit.

Templates prontos em github.com/github/gitignore.

3. Branches

3.1 Conceito

Branch = linha paralela de desenvolvimento.

main:  A--B--C--D-----------M
              \             /
feature:       E--F--G------/

Permite experimentar sem afectar o resto. Standard moderno.

3.2 Branches no Git

# Listar branches
git branch

# Listar todas (incluir remotas)
git branch -a

# Criar nova branch
git branch feature/login

# Mudar para branch
git checkout feature/login
# ou (moderno)
git switch feature/login

# Criar + mudar de uma vez
git checkout -b feature/login
# ou
git switch -c feature/login

# Apagar branch (local)
git branch -d feature/login

# Forçar apagar (mesmo se não foi merged)
git branch -D feature/login

# Renomear branch actual
git branch -m novo-nome

3.3 Merging

# Estar na branch destino (geralmente main)
git checkout main

# Trazer mudanças da feature
git merge feature/login

# Apagar feature após merge bem-sucedido
git branch -d feature/login

Fast-forward merge (sem commits paralelos):

Antes:  main:  A--B--C
                       \
        feature:        D--E

Depois: main:  A--B--C--D--E (linear)

3-way merge (com commits paralelos):

Antes:  main:  A--B--C--D
                  \
        feature:   E--F

Depois: main:  A--B--C--D----M
                  \         /
        feature:   E--F----/  (M = commit de merge)

3.4 Merge vs Rebase

Merge: cria commit extra. - Histórico fiel (mostra exactamente como aconteceu). - Pode parecer "messy" com muitas branches.

Rebase: reescreve commits da feature como se tivessem sido feitos após o último commit de main.

# Estar na feature branch
git checkout feature/x

# Rebase em cima de main
git rebase main

Antes:  main:  A--B--C--D
                  \
        feature:   E--F

Depois: main:  A--B--C--D
                       \
        feature:        E'--F'  (commits reescritos)

Histórico linear mais limpo.

⚠️ Cuidado: não rebase commits já publicados (push). Reescreve histórico e estraga repo de outros.

Regra de ouro: - Rebase branches locais. - Merge branches públicos.

3.5 Branching strategies

Git Flow (clássico, complexo): - main: produção. - develop: integração. - feature/*: novas features. - release/*: preparação release. - hotfix/*: correcções urgentes.

Para projectos grandes.

GitHub Flow (simples, moderno, recomendado): - main: sempre deployable. - feature/*: branches curtas.

Fluxo: 1. Branch from main. 2. Commit changes. 3. Push to GitHub. 4. Open PR. 5. Review + discuss. 6. Merge to main. 7. Deploy.

Trunk-based development (alto-desempenho): - main apenas. - Pequenas branches de horas. - Feature flags para incomplete features.

4. GitHub

4.1 O que é

GitHub = plataforma cloud para hospedar repositórios Git.

Funcionalidades: - Hosting de código. - Colaboração: PRs, code review. - Issues: gestão de bugs/features. - Projects: kanban para gestão. - Actions: CI/CD automation. - Pages: sites estáticos gratuitos. - Codespaces: ambientes de dev cloud. - Discussions: fóruns. - Wiki: documentação.

Versões: - Free: repos públicos e privados ilimitados, 2 GB Actions/mês. - Pro (4 €/mês): mais recursos. - Team / Enterprise: organizações.

Alternativas: - GitLab: open-source, on-premise possível. - Bitbucket (Atlassian): integração com Jira. - Codeberg: 100% open-source, gratuito.

4.2 Criar conta

  1. github.com → Sign up.
  2. Username (público, escolhe bem — aparece em URLs).
  3. Email.
  4. Password.
  5. Verificar email.
  6. Profile setup (foto, bio, link).

4.3 Criar repositório

  1. New repository (botão verde).
  2. Repository name: kebab-case standard (meu-projecto).
  3. Description (opcional mas recomendado).
  4. Public ou Private.
  5. Initialize with README (recomendado).
  6. Add .gitignore: template para linguagem.
  7. Add license: MIT é safe default.
  8. Create repository.

4.4 Conectar local a GitHub

Projecto local existente:

# No directório do projecto local
git remote add origin git@github.com:utilizador/repo.git

# Primeira push
git push -u origin main

# Pushes seguintes
git push

Clonar repo do GitHub:

git clone git@github.com:utilizador/repo.git
cd repo
# Trabalhar normalmente

4.5 SSH vs HTTPS

HTTPS:

https://github.com/user/repo.git

SSH (recomendado):

git@github.com:user/repo.git

Setup SSH:

# 1. Gerar chave SSH
ssh-keygen -t ed25519 -C "teu.email@example.com"
# Premir Enter para localização default
# Passphrase opcional (segurança extra)

# 2. Iniciar ssh-agent
eval "$(ssh-agent -s)"

# 3. Adicionar chave ao agent
ssh-add ~/.ssh/id_ed25519

# 4. Copiar chave pública
cat ~/.ssh/id_ed25519.pub
# Copiar todo o output

# 5. No GitHub:
# Settings → SSH and GPG keys → New SSH key
# Colar e dar nome (ex: "Laptop pessoal")

# 6. Testar
ssh -T git@github.com
# Hi user! You've successfully authenticated...

4.6 Repository structure

Repos típicos têm:

meu-projecto/
├── .github/              # Configurações GitHub (Actions, templates)
│   ├── workflows/
│   └── ISSUE_TEMPLATE/
├── src/                  # Código fonte
├── tests/                # Testes
├── docs/                 # Documentação
├── .gitignore            # Ficheiros ignorados
├── README.md             # Visão geral (importante!)
├── LICENSE               # Licença
├── CONTRIBUTING.md       # Como contribuir
├── CHANGELOG.md          # Histórico de versões
├── package.json          # Metadata + dependencies (Node.js)
│  / requirements.txt     # Python
│  / Cargo.toml           # Rust
│  / pom.xml              # Java Maven
└── ...

4.7 README.md

Crítico — primeira coisa que utilizadores vêem.

Estrutura recomendada:

# Project Name

[![Build](https://img.shields.io/...)] [![License](https://img.shields.io/...)]

One-line description.

## Features

- Feature 1
- Feature 2

## Installation

```bash
npm install

Usage

const lib = require('lib');
lib.doStuff();

Documentation

See docs/ for full documentation.

Contributing

See CONTRIBUTING.md.

License

MIT — see LICENSE.

**Markdown** syntax simples permite formatação rica.

---

## 5. Pull Requests

### 5.1 Workflow

**Standard GitHub Flow com PR**:

  1. Clone repo (ou Fork se contribuição externa) git clone git@github.com:org/repo.git

  2. Branch nova git checkout -b feature/add-login

  3. Trabalhar (edit files) git add . git commit -m "feat: add login form"

  4. Push para o GitHub git push -u origin feature/add-login

  5. Abrir Pull Request no GitHub (interface web)

  6. Code review (comentários, discussão)

  7. Aprovação + Merge (botão Merge no GitHub)

  8. Deletar branch git checkout main git pull git branch -d feature/add-login

### 5.2 Anatomia de um PR

**Header**:
- Título descritivo (e.g., "Add user authentication").
- Branch source → branch target.
- Status (Open, Closed, Merged).

**Description**:
- O que faz.
- Por que.
- Como testar.
- Linked issues (`Closes #123`).
- Screenshots / GIFs.

**Conversation**:
- Comentários gerais.
- Status updates.

**Files changed**:
- **Diff** colorido (verde = adicionado, vermelho = removido).
- Comentários in-line por linha.

**Commits**:
- Lista de commits incluídos no PR.

**Checks**:
- CI status (testes, lint).
- Bots (Dependabot, etc.).

**Reviewers**:
- Pessoas atribuídas para review.

**Labels**:
- Tags (bug, feature, docs, etc.).

### 5.3 PR template

Configurar template no repo (`.github/pull_request_template.md`):

```markdown
## Description

Brief description of what this PR does.

## Type of change

- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## How to test

1. Step 1
2. Step 2
3. Step 3

## Checklist

- [ ] Code follows project style guidelines
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] Self-review done
- [ ] No console.log / debugging code left

## Screenshots

(if applicable)

## Related issues

Closes #123

5.4 Code review — como reviewer

Comportamento:

✅ Ler todo o PR antes de comentar. ✅ Comentar específico (linha por linha). ✅ Construtivo, não destrutivo. ✅ Perguntar em vez de afirmar ("Will this work for X case?"). ✅ Sugerir alternativas com código. ✅ Reconhecer boas práticas. ✅ Aprovar se OK.

Que procurar:

Tipos de comentários:

5.5 Code review — como autor

✅ PRs pequenos (< 400 linhas). ✅ Descrição completa. ✅ Self-review antes de pedir review. ✅ Tests passing. ✅ Responder a todos os comentários (mesmo "OK, fixed"). ✅ Não levar pessoal críticas. ✅ Iterar rapidamente.

❌ PRs gigantes (1000+ linhas). ❌ Ignorar comentários. ❌ Discutir tom agressivo (mesmo se review é). ❌ Defender quando crítica é válida.

5.6 Merge strategies

3 opções no GitHub:

1. Merge commit (padrão):

main:  A--B--C--M  (M = commit de merge)
            \  /
feature:     D-E

Preserva histórico completo.

2. Squash and merge:

main:  A--B--C--F  (F = todos D, E combinados em 1)

Histórico linear, perde detalhe individual.

3. Rebase and merge:

main:  A--B--C--D'--E'  (D, E reescritos linearmente)

Linear + preserva commits.

Recomendação: - Squash: para features grandes (1 commit por feature). - Merge: para projectos onde histórico detalhado é valioso. - Rebase: para projectos com cultura de commits limpos.

6. Workflow profissional

6.1 GitHub Flow detalhado

Cenário: developer trabalha em feature numa equipa.

Passo 1 — Sincronizar:

git checkout main
git pull

Passo 2 — Criar branch:

git checkout -b feature/add-user-profile

Convenção de nomes: - feature/short-description - fix/issue-number-description - chore/update-deps - docs/update-readme

Passo 3 — Trabalhar:

# Editar ficheiros
# Verificar
git status
git diff

# Commits frequentes
git add ficheiro.js
git commit -m "feat(profile): add profile page route"

# (mais mudanças)
git add ficheiro2.js
git commit -m "feat(profile): add profile component"

git add tests/
git commit -m "test(profile): add unit tests for profile component"

Passo 4 — Push (regularmente):

git push -u origin feature/add-user-profile  # primeira vez
git push  # seguintes

Passo 5 — Abrir PR: - GitHub mostra banner "Compare & pull request" após push. - Ou: Pull Requests → New pull request. - Preencher template. - Adicionar reviewers. - Linkar issues. - Adicionar labels.

Passo 6 — Aguardar review: - CI corre (testes, lint). - Reviewers comentam.

Passo 7 — Responder a comentários:

# Fazer mudanças localmente
git add .
git commit -m "fix: address review comments"
git push

Cada push actualiza o PR automaticamente.

Passo 8 — Aprovação: - Reviewers aprovam. - CI passa. - "Merge pull request" button activo.

Passo 9 — Merge: - Escolher merge strategy. - Merge. - (Geralmente "Delete branch" automático após merge).

Passo 10 — Limpar:

git checkout main
git pull
git branch -d feature/add-user-profile

6.2 Convenções de commit

Conventional Commits format:

<type>(<scope>): <subject>

<body>

<footer>

Types: - feat: new feature. - fix: bug fix. - docs: documentation only. - style: formatting (no logic change). - refactor: code restructure (no functional change). - test: adding tests. - chore: maintenance. - perf: performance improvement. - build: build system / dependencies. - ci: CI configuration. - revert: revert previous commit.

Scope (opcional): área afectada (auth, cart, ui, api).

Subject: - Imperativo: "add" not "added". - < 50 chars. - Minúsculas. - Sem ponto final.

Body (opcional): - Por que esta mudança. - O que faz diferente do anterior. - < 72 chars por linha.

Footer (opcional): - Closes #123 para fechar issues. - Breaking change: ... para incompatibilidades.

Exemplos:

feat(auth): add OAuth2 Google login

Implement Google OAuth2 flow with passport.js library.
Users can now sign in with their Google account.

Closes #234

fix(cart): correct tax calculation for EU

Tax was incorrectly using US rates for EU customers.
Now uses country-specific rates from TaxService.

Fixes #567

docs(readme): update installation instructions

Add Windows-specific setup steps.
Mention Node.js 18+ requirement.

refactor(user): extract validation logic to separate module

No functional changes. Improves testability and reuse.

6.3 Hooks

Git hooks: scripts que correm em eventos (pre-commit, pre-push, etc.).

Casos comuns:

pre-commit: - Correr linter. - Verificar formatação. - Correr testes rápidos. - Verificar secrets (não commitar passwords).

commit-msg: - Validar formato da mensagem (conventional commits).

pre-push: - Correr testes completos. - Verificar build.

Ferramentas: - Husky (Node.js): configura hooks facilmente. - pre-commit (Python): framework universal.

Exemplo Husky:

npx husky-init
# Adiciona .husky/pre-commit que corre "npm test"

6.4 GitHub Actions (CI/CD)

Continuous Integration / Continuous Deployment:

# .github/workflows/ci.yml
name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test
      - run: npm run lint

Eventos comuns: - push: a cada push. - pull_request: ao abrir/actualizar PR. - schedule: cron. - release: ao publicar release.

Marketplace de actions: github.com/marketplace.

7. Conflitos

7.1 Quando ocorrem

Quando duas branches modificam a mesma linha do mesmo ficheiro:

git merge feature/x
# Auto-merging file.txt
# CONFLICT (content): Merge conflict in file.txt
# Automatic merge failed; fix conflicts and then commit the result.

git status mostra:

both modified: file.txt

7.2 Anatomia do conflito

Ficheiro com conflito:

function greet(name) {
<<<<<<< HEAD
    return "Hello " + name;
=======
    return `Hello, ${name}!`;
>>>>>>> feature/template-strings
}

7.3 Resolver

Editar manualmente:

  1. Decidir qual versão manter (ou combinar):
function greet(name) {
    return `Hello, ${name}!`;  // mantida versão da feature
}

  1. Remover marcadores: <<<<<<<, =======, >>>>>>>.

  2. Marcar como resolvido:

git add file.txt
  1. Commit:
git commit
# Editor abre com mensagem de merge automática
# Aceitar ou editar

7.4 Estratégias

Preferir uma versão completa:

# Manter versão actual (descartar da feature)
git checkout --ours file.txt

# Manter versão da feature (descartar actual)
git checkout --theirs file.txt

Abortar merge:

git merge --abort
# Volta ao estado anterior ao merge

Ferramentas visuais:

7.5 Prevenção

Como minimizar conflitos:

  1. Branches curtas (vida < 1 semana).
  2. Sincronizar com main regularmente: bash git checkout feature/x git rebase main # ou merge main
  3. Comunicar com equipa sobre quem trabalha em que.
  4. Estrutura modular do código (cada um no seu módulo).
  5. Estilo de código consistente (linter automático).

7.6 Recuperação de "estragar tudo"

Reflog salva tudo:

git reflog
# Mostra todas as operações recentes
# abc123 HEAD@{0}: commit: ...
# def456 HEAD@{1}: merge feature/x: ...
# ...

# Voltar a estado anterior
git reset --hard HEAD@{2}

Reflog mantém histórico mesmo após reset hard. Git é muito difícil de "perder" trabalho.

8. Boas práticas

8.1 Commits

✅ Pequenos e atómicos (1 propósito por commit). ✅ Mensagens claras e descritivas. ✅ Conventional commits. ✅ Verbos no imperativo ("Add" não "Added"). ✅ Inglês (norma internacional). ✅ Frequentes (vários por dia). ✅ Código que compila em cada commit.

❌ Commits gigantes (50+ ficheiros). ❌ "fix" / "wip" / "asdf" como mensagem. ❌ Commits com código que não compila. ❌ Misturar refactor com nova feature.

8.2 Branches

✅ Naming claro: feature/add-login, fix/checkout-bug. ✅ Vida curta (< 1 semana). ✅ Sync com main regularmente. ✅ Apagar após merge.

❌ Branches eternas (3+ meses). ❌ Nomes vagos: temp, test, branch1. ❌ Commits directos para main (em equipas).

8.3 PRs

✅ Pequenos (< 400 linhas). ✅ 1 propósito por PR. ✅ Descrição completa. ✅ Tests incluídos. ✅ Self-review antes de submeter. ✅ CI passing. ✅ Review antes de merge.

❌ PRs gigantes (1000+ linhas). ❌ Misturar várias features. ❌ Self-merge sem review.

8.4 Segurança

⚠️ NUNCA commitar: - Passwords. - API keys (AWS, GCP, etc.). - Secret tokens. - Private keys (.pem, .key). - Dados pessoais.

Use: - .env para configs sensíveis. - .env.example (commitable) como template. - Variáveis de ambiente em produção. - Secrets management (GitHub Secrets, AWS Secrets Manager).

Se acidentalmente commitou secret:

  1. Revogar imediatamente a chave/password.
  2. Mudar para nova.
  3. Limpar histórico: ```bash # BFG Repo-Cleaner (recomendado) bfg --replace-text passwords.txt

# Ou git filter-branch (avançado) ``` 4. Force push (cuidado em repos partilhados).

Mesmo apagando do código actual, fica no histórico. Tem que limpar histórico.

8.5 Colaboração

✅ Comunicar mudanças disruptivas. ✅ Documentar decisões em commits / PRs. ✅ Code review construtivo. ✅ Não force push branches partilhadas. ✅ Manter main estável.

❌ Quebrar build sem aviso. ❌ Code review agressivo. ❌ Force push sem coordenação.

8.6 Ferramentas adicionais

GUI clients: - GitHub Desktop (oficial, simples). - GitKraken (poderoso, multi-plataforma). - SourceTree (Atlassian, gratuito). - Tower (Mac, profissional).

IDE integration: - VSCode: integração nativa excelente. - JetBrains (IntelliJ, PyCharm): integração completa. - GitLens extension (VSCode): ainda mais funcionalidades.

CLI helpers: - GitHub CLI (gh): gh pr create, gh issue list, etc. - tig: TUI browser de commits.

9. Workflow exemplo end-to-end

Cenário: contribuir para projecto open-source no GitHub

Passo 1 — Fork: 1. Ir ao repo (ex: github.com/facebook/react). 2. Clicar Fork (cima direita). 3. Cria cópia em github.com/teu-username/react.

Passo 2 — Clone:

git clone git@github.com:teu-username/react.git
cd react

Passo 3 — Configurar upstream:

git remote add upstream git@github.com:facebook/react.git
git remote -v
# origin    git@github.com:teu-username/react.git (fetch/push)
# upstream  git@github.com:facebook/react.git (fetch/push)

Passo 4 — Sincronizar com upstream:

git checkout main
git fetch upstream
git merge upstream/main
git push  # actualiza teu fork

Passo 5 — Branch para feature:

git checkout -b fix/typo-in-readme

Passo 6 — Trabalhar:

# Editar README.md
git add README.md
git commit -m "docs: fix typo in installation section"

Passo 7 — Push:

git push -u origin fix/typo-in-readme

Passo 8 — Abrir PR: - GitHub mostra "Compare & pull request" no teu fork. - Clicar. - Verificar: - base: facebook:main. - compare: teu-username:fix/typo-in-readme. - Preencher template. - Submit.

Passo 9 — Code review: - Maintainers analisam. - Possíveis comentários. - Iterar até aprovação.

Passo 10 — Merge: - Maintainer faz merge (não tu). - Branch pode ser apagada do teu fork.

Passo 11 — Sincronizar após merge:

git checkout main
git fetch upstream
git merge upstream/main  # incluí o teu PR agora!
git push
git branch -d fix/typo-in-readme

🎉 Contribuiste para projecto open-source.

Apêndice A · Cheat sheet

# === Setup ===
git config --global user.name "Nome"
git config --global user.email "email@x.com"

# === Iniciar ===
git init                          # repo novo
git clone <url>                   # clonar repo

# === Status ===
git status                        # ver estado
git diff                          # ver mudanças
git diff --staged                 # ver staged

# === Commit ===
git add <ficheiro>                # stage ficheiro
git add .                         # stage tudo
git commit -m "mensagem"          # commit
git commit -am "mensagem"         # add + commit (tracked)

# === Histórico ===
git log                           # ver histórico
git log --oneline                 # compacto
git log --graph --all             # visual

# === Branches ===
git branch                        # listar
git branch <nome>                 # criar
git checkout <nome>               # mudar (ou switch)
git checkout -b <nome>            # criar + mudar
git branch -d <nome>              # apagar

# === Merge ===
git merge <branch>                # fundir
git merge --abort                 # abortar
git rebase <branch>               # rebase

# === Remote ===
git remote -v                     # ver remotes
git remote add origin <url>       # adicionar
git push -u origin main           # push primeira vez
git push                          # push
git pull                          # pull (fetch + merge)
git fetch                         # fetch sem merge

# === Desfazer ===
git restore <ficheiro>            # descartar mudanças
git restore --staged <ficheiro>   # remover staging
git reset --soft HEAD~1           # desfazer commit (manter mudanças)
git reset --hard HEAD~1           # desfazer + perder (⚠️)
git revert <commit>               # reverter (commit novo)

# === Stash ===
git stash                         # guardar temporariamente
git stash pop                     # restaurar
git stash list                    # ver lista

# === Tags ===
git tag                           # listar
git tag v1.0.0                    # criar
git push --tags                   # push tags

# === Inspect ===
git show <commit>                 # ver commit
git blame <ficheiro>              # ver quem mudou cada linha
git reflog                        # ver histórico de operações

Apêndice B · Recursos

Apêndice C · Glossário

Mais desta unidade
Vê todos os materiais de UC00617 — slides, sebenta, fichas, projecto e critérios de avaliação: Abrir a unidade →
Recursos grátis para professores · explorar todos os cursos