Git na Prática: O Guia para Desenvolvedores Backend que Estão Começando

Imagem de capa: Git na Prática: O Guia para Desenvolvedores Backend que Estão Começando

O que é controle de versão?

Gerenciar os arquivos do seu projeto é uma tarefa que cresce em complexidade com o projeto. Em um backend, você vai lidar com dezenas de controllers, services, repositórios, arquivos de configuração e scripts de banco de dados. Sem controle de versão, qualquer alteração pode se tornar um risco permanente. O Git resolve isso.

O que é o Git?

O Git é um sistema de controle de versão distribuído amplamente utilizado em todo o mundo. Ele permite que os desenvolvedores acompanhem as mudanças em seus projetos ao longo do tempo, mantendo um histórico completo de todas as modificações. O Git não apenas rastreia as alterações, mas também facilita a colaboração entre membros de uma equipe e o gerenciamento de diferentes recursos de maneira simultânea.

Por que o Git importa para o desenvolvedor backend?

Histórico completo

O Git mantém o registro de todas as alterações feitas no projeto. Imagine que você alterou uma query no repositório JPA e, três semanas depois, uma rota começa a retornar dados errados. Em vez de tentar lembrar o que foi modificado, o Git mostra exatamente quais linhas mudaram — e você pode reverter com um único comando. Nada se perde ou é definitivo.

Colaboração simplificada

Em um cenário sem Git: você escreve o UserService, envia por e-mail para um colega, ele adiciona o AuthService e devolve. Enquanto isso, você não pode avançar sem risco de conflito. O Git gerencia e mescla essas mudanças por você, permitindo que múltiplos devs trabalhem ao mesmo tempo, no mesmo projeto sem sobrescrever o trabalho uns dos outros.

Branches para recursos

Com branches, você pode trabalhar no endpoint de criação de usuário ao mesmo tempo que um colega trabalha no endpoint de autenticação — em branches separadas — e mesclar tudo quando cada um estiver pronto, independentemente do outro.

Jargão essencial do Git

Termo

O que significa

Repository

O projeto inteiro — código + histórico de versões

Working directory

A pasta local onde o projeto existe

Commit

Um "snapshot" salvo das suas alterações

Staging

Marcar arquivos específicos para incluir no próximo commit

Branch

Uma linha paralela de desenvolvimento

Merge

Unir duas branches

Pull Request (PR)

Proposta de alteração revisada antes de ir para a branch principal

Instalação e configuração inicial

Verifique se o Git está instalado:

git --version

git version 2.43.0

Configure seu nome e e-mail (aparecem em todos os seus commits):

git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

Iniciando um repository

Dentro da pasta do seu projeto:

git init
git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/
        pom.xml
        .gitignore


nothing added to commit but untracked files present

Adicionando arquivos e fazendo o primeiro commit

git add .
git commit -m "feat: estrutura inicial do projeto Spring Boot"


[main (root-commit) 4a3f1c2] feat: estrutura inicial do projeto Spring Boot
 12 files changed, 340 insertions(+)
 create mode 100644 pom.xml
 create mode 100644 src/main/java/com/app/Application.java
 create mode 100644 src/main/resources/application.properties

Verificando o histórico de commits

git log --oneline


9f2e1b4 feat: adiciona endpoint GET /users com paginação
7c3d0a1 feat: adiciona UserService e UserRepository
4a3f1c2 feat: estrutura inicial do projeto Spring Boot

Para ver o que mudou em detalhes num commit:

git show 7c3d0a1


commit 7c3d0a1...
Author: Seu Nome <seu@email.com>
Date:   Mon Mar 24 14:22:10 2025

    feat: adiciona UserService e UserRepository

diff --git a/src/main/java/com/app/service/UserService.java b/src/main/java/com/app/service/UserService.java
new file mode 100644
index 0000000..e5c3a12
--- /dev/null
+++ b/src/main/java/com/app/service/UserService.java
@@ -0,0 +1,24 @@
+@Service
+public class UserService {
+    private final UserRepository userRepository;
+    ...
+}

Verificando diferenças antes de commitar

git diff


diff --git a/src/main/java/com/app/controller/UserController.java b/...
index a3c1f2e..9b4d0c7 100644
--- a/src/main/java/com/app/controller/UserController.java
+++ b/src/main/java/com/app/controller/UserController.java
@@ -12,6 +12,11 @@ public class UserController {
     public ResponseEntity<List<User>> getAll() {
         return ResponseEntity.ok(userService.findAll());
     }
+
+    @PostMapping
+    public ResponseEntity<User> create(@RequestBody @Valid UserDTO dto) {
+        return ResponseEntity.status(201).body(userService.create(dto));
+    }
 }

Revertendo para um commit anterior

git checkout 4a3f1c2

Com o Git, você pode restaurar arquivos a qualquer estado anteriormente commitado — mesmo que tenham sido excluídos ou modificados. Porém, se o repositório existir apenas localmente e você perder o computador, o projeto vai junto. Por isso, hospedagem remota (como o GitHub) é indispensável.

.gitignore: o que todo dev backend precisa configurar agora

O .gitignore instrui o Git a não rastrear determinados arquivos — segredos, dependências e artefatos de build não devem ir para o repositório.

Para projetos Spring Boot (Java/Maven):

# Maven
target/
*.jar
*.war
*.class

# IDE
.idea/
*.iml
.vscode/
*.suo

# Variáveis de ambiente e segredos
.env
application-local.properties
application-secrets.yml

# Logs
*.log
logs/

# Sistema operacional
.DS_Store
Thumbs.db

Para projetos ASP.NET Core (C#):

# Build
bin/
obj/
*.user

# IDE
.vs/
*.suo
.vscode/

# Segredos e configuração local
appsettings.Development.json
appsettings.Local.json
*.pfx
secrets.json

# Logs e temporários
*.log
*.tmp
Regra de ouro: nunca commite senhas, connection strings ou tokens de API. Use variáveis de ambiente ou ferramentas como dotnet user-secrets / application-local.properties (no .gitignore) para isso.

Meu primeiro workflow real: criando um endpoint de API com Git

Este é o fluxo que você vai usar no dia a dia da maioria das equipes.

Cenário

Você precisa criar o endpoint POST /products em um projeto Spring Boot. Existe um branch main com o código estável em produção.

Passo 1 — Crie um branch para o novo recurso

git checkout -b feature/create-product-endpoint

Switched to a new branch 'feature/create-product-endpoint'

Passo 2 — Desenvolva o recurso

Você cria o ProductController, ProductService, ProductRepository e o ProductDTO. A estrutura fica assim:

src/main/java/com/app/
├── controller/
│   └── ProductController.java   ← novo
├── service/
│   └── ProductService.java      ← novo
├── repository/
│   └── ProductRepository.java   ← novo
└── dto/
    └── ProductDTO.java          ← novo

Passo 3 — Adicione ao staging e commit

git add src/main/java/com/app/
git status

On branch feature/create-product-endpoint
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file: src/main/java/com/app/controller/ProductController.java
        new file: src/main/java/com/app/service/ProductService.java
        new file: src/main/java/com/app/repository/ProductRepository.java
        new file: src/main/java/com/app/dto/ProductDTO.java

git commit -m "feat: adiciona endpoint POST /products com validação"

[feature/create-product-endpoint 3b8f9c1] feat: adiciona endpoint POST /products com validação
 4 files changed, 98 insertions(+)

Passo 4 — Envie o branch para o GitHub e abra um Pull Request

git push origin feature/create-product-endpoint

Enumerating objects: 12, done.
Counting objects: 100% (12/12), done.
Delta compression using up to 8 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.23 KiB | 1.23 MiB/s, done.
remote: Create a pull request for 'feature/create-product-endpoint' on GitHub by visiting:
remote:   https://github.com/seu-usuario/seu-projeto/pull/new/feature/create-product-endpoint

Abra o link, descreva o que foi feito, peça revisão a um colega e, após aprovação, faça o merge para main.

Branches: GitFlow e Trunk-Based Development

Saber criar branches é o começo. Entender como as equipes organizam esses branches é o que separa um dev júnior de alguém que está pronto para trabalhar em produção.

GitFlow

O GitFlow usa um conjunto fixo de branches com papéis definidos:

  • main — código em produção, sempre estável
  • develop — integração de novas funcionalidades
  • feature/nome — desenvolvimento de um recurso específico
  • release/x.x — preparação para uma nova versão
  • hotfix/nome — correções urgentes diretamente em produção

É um modelo mais formal, comum em equipes com ciclos de release definidos (ex.: sistemas corporativos, APIs com versionamento explícito).

Trunk-Based Development

Aqui, todos os devs commitam diretamente (ou em branches de curtíssima duração) na branch principal (main / trunk). Features incompletas são protegidas por feature flags no código. É o modelo preferido por equipes que fazem deploy contínuo (CI/CD), muito comum em startups e produtos SaaS.

Na prática, a maioria trabalha com uma variação simplificada do GitFlow — main, develop e branches de feature.

Hospedagem de repository com GitHub

Git gerencia versões localmente; o GitHub guarda o repositório num servidor e permite colaboração remota.

# Conecta seu repo local a um repositório remoto no GitHub
git remote add origin https://github.com/seu-usuario/seu-projeto.git

# Envia o código local para o GitHub
git push -u origin main

Pull Request e Code Review

Um pull request é uma proposta de alteração. Antes de ir para main, o código passa por revisão: um colega lê o diff, comenta, sugere melhorias. Só após aprovação a branch é mesclada. Esse processo é padrão na indústria.

Próximos passos

Agora que você tem a base, aprofunde-se nessas direções:

  1. Resolução de conflitos de merge — acontece quando dois devs alteram o mesmo trecho de código. Saber resolver manualmente é essencial.
  2. Git rebase — alternativa ao merge para manter um histórico linear. Muito usado em equipes que prezam por um log limpo.
  3. Commits convencionais — padrão feat:, fix:, chore:, docs: que você já viu nos exemplos acima. Facilita geração de changelogs automáticos.
  4. GitHub Actions — automação de testes e deploy disparados por push ou PR. O próximo passo natural após dominar o Git.
  5. Git Book (oficial): https://git-scm.com/book/pt-br/v2
  6. GitHub Skills (hands-on): https://skills.github.com
  7. Aula do MIT sobre controle de versionamento: https://missing.csail.mit.edu/2020/version-control/

Git é o padrão da indústria — e dominá-lo não é opcional para quem quer trabalhar com desenvolvimento de software. Quanto antes você transformar esses comandos em hábito, mais rápido você vai se sentir a vontade num time de verdade.

Gostou deste artigo? Compartilhe!