Git + GitLab na prática: criar branch, enviar, abrir MR, dar merge e limpar branch

🚀 Git + GitLab na prática: branch, merge e limpeza sem dor de cabeça

Este guia é um passo a passo direto ao ponto para o fluxo mais comum no Git/GitLab:

• 🌱 Criar um novo branch
• 📤 Enviar para o GitLab e fazer merge com main
• 🧹 Voltar para o branch principal e apagar o branch local

---

✅ Pré-check (altamente recomendado)

Antes de qualquer coisa, confira em qual branch você está:

git branch

Atualize seu main local antes de criar novos branches:

git checkout main
git pull origin main

---

🌱 1) Como criar um novo branch

Opção A (recomendada)

Crie o branch sempre a partir do main atualizado:

git checkout main
git pull origin main
git checkout -b feature/nome-da-feature

📌 Exemplo real:

git checkout -b feature/projetos

Opção B (Git moderno)

git switch main
git pull origin main
git switch -c feature/projetos

---

📤 2) Já fiz commit. Como enviar para o GitLab e fazer merge?

2.1 Enviar o branch para o remoto

Primeiro push do branch:

git push -u origin feature/projetos

Pushs seguintes:

git push

2.2 Criar o Merge Request no GitLab

1. 🌐 Abra o repositório no GitLab
2. 🔀 Vá em Merge Requests → New merge request
3. Selecione:
   • Source: feature/projetos
   • Target: main
4. ✅ Crie o MR e clique em Merge quando estiver pronto

⚠️ Boa prática antes do merge

Traga o main mais recente para dentro do seu branch:

git fetch origin
git checkout feature/projetos
git merge origin/main
git add .
git commit
git push

💡 Algumas equipes preferem rebase. Se for o seu caso:

git fetch origin
git checkout feature/projetos
git rebase origin/main
git push --force-with-lease

---

🧹 3) Voltar para o main e apagar o branch local

3.1 Voltar para o branch principal

git checkout main
git pull origin main

3.2 Apagar o branch local após o merge

Forma segura (recomendada):

git branch -d feature/projetos

⚠️ Se o Git reclamar que não está mergeado:

git pull origin main
git branch -d feature/projetos

🔥 Forçar exclusão (use só se tiver certeza):

git branch -D feature/projetos

3.3 Limpar referências de branches remotos

git fetch --prune

---

📌 Checklist final (salva-vidas)

# criar branch
git checkout main
git pull origin main
git checkout -b feature/projetos

# trabalhar, commitar, enviar
git add .
git commit -m "feat: projetos"
git push -u origin feature/projetos

# (GitLab) abrir MR → merge

# voltar ao main e limpar branch
git checkout main
git pull origin main
git branch -d feature/projetos
git fetch --prune

✅ Pronto! Fluxo limpo, previsível e profissional.

PostgreSQL e IDENTITY: por que a sequência “desalinha” e como corrigir

Se você usa PostgreSQL, provavelmente já viu (ou vai ver) um erro como:

ERROR: duplicate key value violates unique constraint
DETAIL: Key (id)=(2) already exists.

Esse erro costuma aparecer quando uma coluna IDENTITY (ou SERIAL) está tentando gerar um ID que já existe na tabela. Na prática, isso significa que a sequência interna do PostgreSQL ficou desalinhada com os dados.

Neste artigo você vai entender:

• o que é a sequência interna (sequence) do IDENTITY
• por que ela pode “perder o valor correto”
• como diagnosticar o problema
• como ajustar a sequência com segurança

---

1) O que é IDENTITY no PostgreSQL?

Uma coluna definida como GENERATED ... AS IDENTITY gera valores automaticamente usando uma sequence (sequência) por trás.

Exemplo:

CREATE TABLE exemplo (
  id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  nome text NOT NULL
);

O PostgreSQL cria uma sequence interna (com um nome próprio) e passa a usar algo como:

nextval('nome_da_sequence')

para gerar IDs automaticamente.

---

2) Por que a sequência pode “desalinhar”?

O ponto mais importante é este:

A sequence é independente da tabela. Ela não “olha” os dados para decidir o próximo número.

Ou seja: a tabela pode ter ID 1000, mas se a sequence ainda estiver em 10, o próximo insert automático pode tentar gerar 11, 12... e em algum momento pode gerar um valor que já existe, causando erro.

Motivos comuns (na prática)

• Importação/carga de dados inserindo IDs manualmente (ex.: INSERT com id=1000)
• Restore de backup onde os dados voltam, mas a sequence não é ajustada
• Scripts de migração ou manutenção que inserem IDs explicitamente
• TRUNCATE/DELETE (a tabela muda, mas a sequence mantém o valor antigo)
• Testes/seed com dados fixos e IDs definidos “na mão”

---

3) Como diagnosticar se a sequence está errada

O diagnóstico clássico compara:

• maior ID da tabela vs
• valor atual da sequence

3.1 Descobrir o nome da sequence associada ao IDENTITY

SELECT pg_get_serial_sequence('schema.tabela', 'coluna_id');

Exemplo:

SELECT pg_get_serial_sequence('public.exemplo', 'id');

O retorno será o nome da sequence (por exemplo public.exemplo_id_seq).

3.2 Ver o maior ID existente na tabela

SELECT MAX(id) FROM public.exemplo;

3.3 Ver o valor atual da sequence

SELECT last_value FROM public.exemplo_id_seq;

Se last_value for menor que o MAX(id), você tem um desalinhamento.

---

4) Como ajustar a sequência do IDENTITY (forma segura)

A correção consiste em configurar a sequence para continuar a partir do maior ID existente.

4.1 Ajuste automático usando o máximo da tabela

SELECT setval(
  pg_get_serial_sequence('schema.tabela', 'coluna_id'),
  (SELECT COALESCE(MAX(coluna_id), 1) FROM schema.tabela)
);

Exemplo completo:

SELECT setval(
  pg_get_serial_sequence('public.exemplo', 'id'),
  (SELECT COALESCE(MAX(id), 1) FROM public.exemplo)
);

Após isso, o próximo INSERT automático usará MAX(id) + 1.

---

5) Caso especial: tabela vazia

Se a tabela estiver vazia e você quiser reiniciar a contagem, use o terceiro parâmetro do setval:

SELECT setval(
  pg_get_serial_sequence('public.exemplo', 'id'),
  1,
  false
);

O false indica que o próximo valor gerado será exatamente 1.

---

6) Por que “buracos” em IDs são normais

Um detalhe que muita gente estranha:

Sequences não fazem rollback. Elas avançam mesmo se a transação falhar.

Exemplo:

BEGIN;
INSERT INTO public.exemplo (nome) VALUES ('Teste');
ROLLBACK;

Mesmo com rollback, a sequence pode ter incrementado. Isso gera “buracos” nos IDs, e isso é esperado. IDs não devem ser usados como números contábeis ou sequenciais perfeitos.

---

7) Boas práticas para evitar o problema

• Evite inserir IDs manualmente. Se precisar, ajuste a sequence depois.
• Após restore/importações, sempre valide MAX(id) vs sequence.
• Crie um checklist pós-deploy para checar sequences.
• Em migrações, prefira inserir sem ID e deixar o banco gerar.

---

Conclusão

Quando o PostgreSQL “tenta repetir um ID”, quase sempre o problema é a sequence interna do IDENTITY que ficou atrás do maior valor real da tabela.

A correção é simples e segura usando setval alinhado ao MAX(id). Com isso, você evita erros de chave duplicada e mantém o banco saudável mesmo após importações ou restores.

Se você quiser, eu posso publicar uma versão complementar mostrando:

• como resetar sequences em lote para um schema inteiro
• como fazer isso no contexto do Django (sqlsequencereset)
• como automatizar validação pós-deploy

Tabelas Padrão do Django: Autenticação, Permissões e Infraestrutura

 

Entendendo as Tabelas Padrão do Django: Autenticação, Permissões e Infraestrutura

Quando iniciamos um projeto com Django, várias tabelas são criadas automaticamente no banco de dados. Para quem olha pela primeira vez, nomes como auth_group, django_content_type ou django_migrations podem parecer confusos.

Este artigo explica para que serve cada uma dessas tabelas, como elas se relacionam e quando você deve (ou não) interagir com elas.

Atenção: a maioria dessas tabelas faz parte da infraestrutura do framework. Elas não são tabelas de negócio.

---

Visão geral

As tabelas padrão do Django podem ser agrupadas em quatro grandes áreas:

1. Autenticação (quem é o usuário)
2. Autorização (o que o usuário pode fazer)
3. Infraestrutura interna do framework
4. Sessão e estado

---

1. Tabelas de Autenticação

auth_user

É a tabela central de usuários autenticáveis do Django.

Ela armazena informações como:

• nome de usuário
• senha (sempre em hash)
• e-mail
• flags de acesso (is_active, is_staff, is_superuser)
• datas de login e criação

Essa tabela é usada pelo sistema de login, logout e controle de acesso.

Boa prática: use auth_user para autenticação, não como entidade de negócio (ex.: funcionário, cliente, aluno).

---

2. Tabelas de Autorização (Permissões)

auth_permission

Armazena permissões individuais do sistema.

Para cada model Django, o framework cria automaticamente permissões padrão, como:

• adicionar
• alterar
• excluir
• visualizar

Essas permissões são usadas para controlar o acesso a funcionalidades específicas.

auth_group

Representa grupos de usuários.

Um grupo é basicamente um conjunto de permissões que pode ser atribuído a vários usuários.

Exemplos de grupos comuns:

• Administradores
• Editores
• Leitores

auth_group_permissions

Tabela associativa entre:

• grupos
• permissões

Define quais permissões cada grupo possui.

É aqui que o Django resolve a pergunta:

“O que usuários deste grupo podem fazer?”

auth_user_groups

Tabela associativa entre:

• usuários
• grupos

Define a quais grupos cada usuário pertence.

Um usuário pode estar em vários grupos ao mesmo tempo.

auth_user_user_permissions

Tabela associativa entre:

• usuários
• permissões individuais

Permite conceder permissões diretamente a um usuário, sem passar por grupos.

Boa prática: usar grupos sempre que possível e evitar permissões diretas, pois elas dificultam a manutenção.

---

3. Tabelas de Infraestrutura do Django

django_content_type

Registra todos os models instalados no projeto.

Cada registro identifica:

• o app
• o nome do model

Essa tabela é usada internamente pelo Django para:

• sistema de permissões
• Django Admin
• relacionamentos genéricos
• logs

Ela é fundamental para o funcionamento interno do framework.

django_admin_log

Armazena logs de ações realizadas no Django Admin.

Registra informações como:

• qual usuário realizou a ação
• qual objeto foi afetado
• qual operação foi executada (criação, alteração, exclusão)

É muito útil para auditoria administrativa.

django_migrations

Controla quais migrações já foram aplicadas no banco de dados.

Cada vez que você executa python manage.py migrate, o Django consulta essa tabela para saber:

• quais migrações já rodaram
• quais ainda precisam ser aplicadas

Importante: nunca edite ou apague registros dessa tabela manualmente.

---

4. Tabela de Sessão

django_session

Armazena as sessões ativas dos usuários.

É usada para:

• manter usuários logados
• armazenar dados temporários
• mensagens flash
• estados intermediários de formulários

As sessões têm prazo de validade e podem ser limpas automaticamente.

---

Resumo rápido

Tabela	Finalidade
auth_user	Usuários do sistema
auth_group	Grupos / perfis
auth_permission	Permissões
auth_group_permissions	Grupo ↔ Permissão
auth_user_groups	Usuário ↔ Grupo
auth_user_user_permissions	Permissões diretas
django_content_type	Registro de models
django_admin_log	Log do admin
django_migrations	Controle de migrations
django_session	Sessões

---

Boas práticas gerais

• Não manipule essas tabelas diretamente via SQL.
• Use sempre a API do Django (models, admin, permissions).
• Centralize permissões em grupos.
• Use auth_user apenas para autenticação.
• Separe entidades de negócio em tabelas próprias.

---

Conclusão

As tabelas padrão do Django formam a base de segurança e funcionamento do framework. Entendê-las ajuda a:

• modelar sistemas mais seguros
• evitar erros em produção
• criar arquiteturas mais limpas e escaláveis

Mesmo que você nunca precise mexer nelas diretamente, saber para que cada uma existe faz toda a diferença.