Versionamento
Tronco podado — o conteúdo virou domínio próprio
Esta nota era um monólito sobre Git (comandos, merge × rebase, workflows, Conventional Commits, boas práticas). Em 2026-07-31 o assunto ganhou domínio próprio, com 7 níveis do tutorial operacional ao modelo interno: Controle de Versão.
Nada foi perdido — cada seção daqui foi absorvida e expandida numa nota atômica. O mapa está abaixo.
Para onde foi cada coisa
| O que havia aqui | Onde está agora |
|---|---|
| O que é Git, VCS distribuído, história | 01 — O problema que o Git resolve |
Configuração inicial (user.name, user.email) | 02 — Instalar e configurar o Git |
Áreas do Git, add/commit/log, ciclo de vida | 03 — Seu primeiro repositório |
Desfazer: restore, reset, revert, amend | 04 — Desfazer sem susto · árvore de decisão completa na nota 22 (N4) |
Remotos, push/pull/fetch | 05 — GitHub · 11 — Sincronizar com o time |
.gitignore | 06 — Ignorar arquivos |
| Branches, merge × rebase, resolução de conflitos | 08 — Branches na prática · 09 — Conflito · mecanismo por baixo na nota 21 (N3) |
| Stash | 10 — stash e worktrees |
| Git Flow, GitHub Flow, Trunk-Based | 13 — Estratégias de branching |
| Conventional Commits, semver, tags, boas práticas | 14 — Anatomia de um bom commit |
PRs, proteção da main, review | 12 — Pull requests · 15 — GitHub como plataforma |
| Clients gráficos (Sourcetree, GitKraken) | mencionados em 02; TUIs em Terminal |
| Recursos externos e material de estudo | Biblioteca de Controle de Versão |
O que não migrou, e por quê
As duas seções abaixo são material de entrevista, não de trilha: relato pessoal e articulação em inglês. O domínio novo é escrito para público amplo e não incorpora experiência pessoal do autor, então elas ficam preservadas aqui. Se forem trabalhadas, o destino natural é Entrevistas.
Na prática (da minha experiência)
Uso GitHub Flow em todos os projetos — feature branches + PRs + CI obrigatório. Conventional Commits para mensagens padronizadas, o que permite changelogs automáticos. No MedEspecialista, GitHub Actions roda testes e linting em cada PR, e merge só é permitido com review aprovado e checks verdes. Para deploys, tags (
v1.0.0) disparam o pipeline de release.
How to explain in English
“Git is central to my development workflow. I follow GitHub Flow — short-lived feature branches, pull requests with code review, and CI/CD that validates every change before merge to main.
I use Conventional Commits for semantic commit messages, which enables automatic changelog generation and semantic versioning. Each commit should be atomic — doing one thing — so it can be reverted independently if needed.
For branch management, I prefer rebase over merge for feature branches to maintain a clean linear history. I rebase my feature branch on main before opening a PR, resolve any conflicts locally, then the PR shows a clean diff. After review and CI passes, we squash-merge to main.
One thing I always emphasize is protecting the main branch — requiring PR reviews, passing CI checks, and never allowing force pushes. This ensures main is always deployable.”
Key vocabulary
- branch → branch: linha independente de desenvolvimento
- commit → commit: snapshot do código em um ponto no tempo
- merge → merge: combinar branches
- rebase → rebase: reaplicar commits sobre outra base
- stash → stash: guardar mudanças temporariamente
- pull request → pull request (PR): proposta de merge com review
- conflito → merge conflict
- histórico → git history / git log
- tag → tag: marcador de versão
Veja também
- Controle de Versão — o domínio completo
- Terminal