Gerenciamento de Código-Fonte

O gerenciamento de código-fonte (SCM, do inglês Source Code Management) é a disciplina de rastrear, registrar e coordenar cada alteração feita no código-fonte de um projeto ao longo do tempo. Esta página explica o que é SCM, por que todas as equipes dependem dele, como o Git se encaixa nesse contexto, o fluxo de trabalho que ele possibilita e as práticas que mantêm o histórico de um projeto organizado.

O que é Gerenciamento de Código-Fonte?

O gerenciamento de código-fonte é a prática de rastrear e gerenciar alterações no código de software. Ele é quase sempre implementado com um sistema de controle de versão (VCS) — uma ferramenta que registra cada modificação em um repositório, atribui-a a um autor, adiciona um carimbo de data/hora e permite navegar para frente e para trás no histórico do projeto.

O Git é o VCS mais utilizado atualmente. Ele é distribuído, o que significa que cada desenvolvedor mantém uma cópia completa do histórico do projeto localmente, permitindo que você faça commits, crie branches e inspecione o histórico sem uma conexão de rede. Existem outros sistemas (Subversion, Mercurial, Perforce), mas os conceitos desta página se aplicam a todos eles.

SCM e VCS são frequentemente usados de forma intercambiável. Em sentido estrito, SCM é a prática mais ampla (histórico, branching, políticas de colaboração, revisão de código), e um VCS como o Git é a ferramenta que a implementa.

Se você é novo no Git, comece com a introdução ao Git e aprenda como criar seu primeiro repositório Git.

Por que o Gerenciamento de Código-Fonte é Importante

Um VCS resolve problemas que se tornam dolorosos no momento em que mais de uma pessoa — ou mais de um dia de trabalho — toca em uma base de código:

• Rastrear alterações – Cada mudança é registrada automaticamente, atribuída a um autor e documentada com uma mensagem de commit, criando um registro histórico pesquisável.
• Sincronização – Os membros da equipe obtêm o código mais recente de um repositório compartilhado, garantindo que todos trabalhem a partir da mesma base.
• Backup e restauração – Como cada commit é um snapshot completo, qualquer arquivo pode ser restaurado a um estado anterior a qualquer momento.
• Desfazer alterações – Você pode reverter para qualquer estado anterior, do commit mais recente a uma versão criada há muito tempo, sem perder as etapas intermediárias.
• Branching e merging – O trabalho acontece em branches isoladas e é mesclado de volta após revisão e aprovação.
• Detecção de conflitos – Quando duas pessoas alteram as mesmas linhas, o VCS se recusa a sobrescrever silenciosamente uma com a outra; ele sinaliza um conflito de merge para que um humano possa resolvê-lo.

Sem SCM, as equipes recorrem a compactar pastas, enviar arquivos por e-mail e nomear arquivos como final_v2_REALLY_final.js — perdendo o histórico e sobrescrevendo o trabalho uns dos outros.

O Fluxo de Trabalho Básico do SCM

A maior parte do trabalho diário no Git segue o mesmo ciclo: alterar arquivos, prepará-los (staging), fazer um commit de um snapshot e inspecionar o histórico. O exemplo abaixo executa um repositório autocontido para que você possa ver o ciclo do início ao fim.

# Create and enter a fresh project
mkdir scm-demo && cd scm-demo

# 1. Turn the folder into a repository
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

# 2. Make a change
echo "console.log('hello');" > app.js

# 3. Stage the change, then record a snapshot (commit)
git add app.js
git commit -q -m "Add initial app"

# 4. Make a second change and commit it
echo "console.log('world');" >> app.js
git commit -q -am "Print world too"

# 5. Inspect the historical record
git log --oneline

O histórico agora contém dois snapshots, do mais recente para o mais antigo (os hashes curtos à esquerda são gerados por commit, portanto os seus serão diferentes):

6524bb9 Print world too
88e2f34 Add initial app

Cada git add move as alterações para a área de staging, e cada git commit congela o conteúdo preparado em um snapshot permanente e nomeado. A saída do git log é o registro histórico que o SCM oferece — duas linhas aqui, uma por commit, cada uma com um hash curto e uma mensagem. A qualquer momento você pode executar git status para ver o que foi alterado, está em staging ou não está sendo rastreado.

Branching e Merging

O recurso que torna o SCM poderoso para equipes é o isolamento por meio de branches. Cada desenvolvedor (ou cada funcionalidade) tem uma linha de desenvolvimento separada; quando o trabalho é revisado e está pronto, ele é mesclado de volta ao branch principal.

mkdir branch-demo && cd branch-demo
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

echo "line 1" > notes.txt
git add notes.txt
git commit -q -m "Start notes"

# Remember the main branch name (main or master)
main=$(git branch --show-current)

# Create a branch, switch to it, add work there
git switch -c feature
echo "line 2 from feature" >> notes.txt
git commit -q -am "Add feature line"

# Go back to the main branch and merge the feature in
git switch -q "$main"
git merge -q feature

cat notes.txt

Após o merge, notes.txt contém o trabalho de ambas as branches:

line 1
line 2 from feature

A branch feature permitiu que a nova linha de trabalho avançasse sem tocar em main, e o git merge a combinou de volta. Em um projeto compartilhado, você também usaria git clone no repositório e git pull antes de começar, para garantir que está construindo sobre o código mais recente.

Boas Práticas

• Faça commits frequentes e em unidades pequenas. Um commit é um snapshot; commits pequenos e focados oferecem muitos pontos seguros para retornar e tornam o histórico fácil de ler. Commits relacionados podem ser combinados posteriormente para manter o log organizado.
• Sempre trabalhe a partir da versão mais recente. Faça pull ou fetch do código compartilhado antes de começar para que você construa sobre o trabalho atual e minimize conflitos de merge.
• Escreva mensagens de commit descritivas. Uma mensagem clara que explica o que mudou e por quê torna-se essencial à medida que um projeto cresce e outras pessoas (incluindo você no futuro) leem o log.
• Revise antes de fazer commit. A área de staging permite coletar e inspecionar edições antes de transformá-las em um snapshot — revise o diff para que cada commit seja intencional.
• Use branches para isolamento. Desenvolva cada funcionalidade ou correção em sua própria branch e faça o merge somente após revisão, mantendo o branch principal estável.
• Concorde com um fluxo de trabalho compartilhado. Estabeleça convenções de equipe para branching, revisão e merging. Padrões comuns são abordados em fluxos de trabalho do Git.

Prática