1. O Que E o Git e Por Que Usar

Git e um sistema de controle de versao distribuido criado por Linus Torvalds em 2005 para gerenciar o desenvolvimento do kernel Linux. Hoje e o padrao absoluto da industria: mais de 90% dos desenvolvedores usam Git como ferramenta principal de versionamento.

Diferente de sistemas centralizados como SVN, cada desenvolvedor tem uma copia completa do repositorio com todo o historico. Isso permite trabalho offline, branches ultra-rapidos, merges eficientes e uma flexibilidade de fluxo de trabalho sem precedentes.

2. Conceitos Fundamentais

Para dominar o Git, e essencial entender seus tres estados principais:

• Working Directory: onde voce edita os arquivos. Mudancas aqui sao "untracked" ou "modified".
• Staging Area (Index): preparacao para o commit. Voce adiciona mudancas com git add.
• Repository: historico permanente de commits. Criado com git commit.

O HEAD e um ponteiro especial que indica em qual commit ou branch voce esta atualmente. Entender o HEAD e fundamental para operacoes como reset, rebase e checkout.

3. Fluxos de Trabalho

Existem varios fluxos de trabalho Git populares:

• Git Flow: branches main, develop, feature/*, hotfix/* e release/*. Ideal para projetos com releases programados. Mais complexo, mas fornece isolamento claro entre ambientes.
• Trunk-Based Development: todos trabalham em branches de curta duracao derivadas de main/trunk. Ideal para CI/CD continuo e times que fazem deploy frequente.
• GitHub Flow: simplificacao do Git Flow — apenas main e feature branches. Adequado para a maioria dos projetos web modernos.

"Nao existe o fluxo certo para todos. O melhor fluxo e aquele que o seu time entende, segue consistentemente e que viabiliza entregas frequentes com qualidade."

4. Mensagens de Commit e Conventional Commits

Uma boa mensagem de commit e a documentacao mais proxima do codigo. O padrao Conventional Commits define uma estrutura simples: tipo(escopo): descricao.

Os tipos mais comuns sao feat (nova funcionalidade), fix (correcao de bug), docs, refactor, test e chore. Este padrao permite geracao automatica de changelogs e versionamento semantico (SemVer) com ferramentas como semantic-release.

5. Rebase vs Merge: Quando Usar Cada Um

Esta e uma das questoes mais debatidas no mundo Git:

• Merge preserva o historico exato de como o desenvolvimento aconteceu, criando um commit de merge. Mais seguro para branches compartilhados. O historico e honesto mas pode ficar "sujo".
• Rebase reescreve o historico aplicando commits em cima de outro ponto, criando um historico linear e limpo. Nunca faca rebase em branches compartilhados — isso reescreve commits que outros ja baixaram.

Regra pratica: use rebase para limpar commits locais antes de abrir um PR; use merge para integrar branches de feature ao main.

6. Perguntas Frequentes

Como desfazer o ultimo commit sem perder as mudancas?

Use git reset --soft HEAD~1. Isso desfaz o commit mas mantem as mudancas no staging, prontas para um novo commit. Se quiser tambem remover do staging (mas manter nos arquivos), use --mixed. Se quiser descartar tudo, use --hard (cuidado: irreversivel).

Como recuperar um branch ou commit deletado?

Use git reflog para ver o historico de movimentacoes do HEAD. Encontre o hash do commit que voce quer recuperar e use git checkout -b nome-do-branch HASH. O reflog guarda referências por 90 dias por padrao.

Qual a diferenca entre git fetch e git pull?

git fetch baixa as mudancas do remoto mas NAO integra ao seu branch local — voce pode inspecionar antes. git pull e equivalente a git fetch seguido de git merge. Para mais controle, prefira fetch + merge ou fetch + rebase explicitamente.