Fundamentos do Git

Um histórico ao qual você pode voltar

O Git registra o histórico de um projeto como uma série de commits: instantâneos de todos os arquivos rastreados, cada um com autor, hora e mensagem. Com ele você vê o que mudou e por quê, testa uma ideia sem medo e volta a uma versão que funcionava. Uma pasta sob controle do Git é um repositório. O trabalho quantitativo depende muito disso: um resultado só é confiável se você puder dizer exatamente qual versão do código o produziu.

# Start tracking a project (once)
git init

# See what changed, stage it, record it
git status
git add main.py README.md
git commit -m "Add the first backtest loop"

# Look back
git log --oneline
git diff                      # changes not yet staged

Os três lugares onde uma mudança vive

Uma mudança passa por três áreas. Você edita arquivos na árvore de trabalho. git add copia as mudanças escolhidas para a área de preparação (o próximo instantâneo, em preparo). git commit registra o instantâneo preparado no histórico do repositório. Isso permite fazer commit só das mudanças relacionadas, mesmo que você tenha editado muitos arquivos. git status mostra cada arquivo na sua área: modificado, preparado ou não rastreado (novo e ainda desconhecido do Git).

# git status --porcelain prints two status letters, a space, then the path
status = """ M main.py
A  notes.md
?? scratch.txt
D  old.py"""

for line in status.splitlines():
    code, path = line[:2], line[3:]
    print(repr(code), path)
# ' M' main.py     (modified, not staged)
# 'A ' notes.md    (new, staged)
# '??' scratch.txt (untracked)
# 'D ' old.py      (deleted, staged)

Branches

Um branch é um nome móvel para uma linha de commits. Crie um para cada ideia ou correção (git switch -c fee-model), faça commits à vontade e, quando funcionar, traga-o para a linha principal com git merge (em geral a partir do branch main). Nomes de branch podem conter letras, dígitos, -, _, / e ., mas não espaços nem nenhum de ~ ^ : ? * [ \, e não podem começar ou terminar com / nem terminar com .. O Git avisa de conflitos quando dois branches mudaram as mesmas linhas, e você os resolve à mão.

# Try an idea on its own branch, then bring it back
git switch -c fee-model
git commit -am "Use tiered fees"
git switch main
git merge fee-model

# List branches (the current one has a star)
git branch

O que deixar de fora e como desfazer

Um arquivo .gitignore lista os padrões que o Git não deve rastrear: .venv/ (uma pasta, escrita com barra final), *.log (qualquer arquivo que combine com um curinga), secrets.env. Deixe de fora ambientes virtuais, caches, arquivos de dados grandes e, acima de tudo, segredos como chaves de API: tudo o que é commitado permanece no histórico mesmo que você apague depois. Para desfazer, git restore arquivo descarta edições não commitadas de um arquivo, e git revert <commit> adiciona um novo commit que cancela um antigo, o que é seguro em branches compartilhados. git push e git pull trocam commits com uma cópia remota, como uma no GitHub.

# .gitignore
.venv/
__pycache__/
*.log
secrets.env

# Undo safely
git restore main.py            # drop uncommitted edits to one file
git revert 3f2a9c1             # new commit that cancels an old one

# Share
git push origin main
git pull

• git init, git status, git add, git commit -m "...", git log --oneline.
• Um branch por ideia: git switch -c nome e depois git merge.
• Use .gitignore para .venv/, caches, dados e segredos; desfaça com restore ou revert.

A seguir: notebooks Jupyter, para explorar dados de forma interativa e mantê-los organizados sob o Git.

Lab: o que é avaliado

• Classificar os arquivos de um relatório git status com parse_status25 pts
• Ler uma listagem de git log --oneline com parse_log25 pts
• Verificar um nome de branch pelas regras do Git com is_valid_branch_name25 pts
• Aplicar um .gitignore a uma lista de arquivos com not_ignored25 pts