Como Resolver o Erro de Certificado SSL no Git

Se você trabalha em redes corporativas e tentou rodar um pip install ou git clone, provavelmente encontrou este erro frustrante:

O Problema

fatal: unable to access '...': schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325)

Por que isso acontece?

Esse erro ocorre porque o Git (usando o SChannel do Windows) tenta validar o certificado SSL do servidor GitLab interno. Em intranets, é comum o uso de certificados autoassinados ou emitidos por uma CA (Autoridade Certificadora) interna que não está na lista de "raízes confiáveis" do seu sistema operacional.

Como o Windows não consegue garantir que o servidor é quem diz ser, ele bloqueia a conexão para te proteger.

Como Resolver

Solução 1: Variável de Ambiente (Recomendado para uso pontual)

A forma mais rápida no PowerShell, sem precisar alterar configurações globais do Git:

$env:GIT_SSL_NO_VERIFY=$true
pip install git+https://gitlab.intranet.br

Solução 2: Configuração Global do Git

Para não precisar digitar o comando acima toda vez:

git config --global http.sslVerify false

Solução 3: Mudar o Backend de Segurança

Às vezes, forçar o Git a usar o OpenSSL resolve problemas de integração com o Windows:

git config --global http.sslBackend openssl

Dica de Segurança: Embora desativar o SSL facilite o trabalho interno, lembre-se de reativá-lo ao trabalhar com repositórios públicos na internet para garantir sua segurança.

GitLab: Merge do main no seu branch

🔀✅ Fazer Merge do main no seu branch (sem reescrever histórico)

Se alguém acabou de fazer merge no main no GitLab e você está trabalhando em outro branch, o caminho mais simples e seguro é: trazer o main atualizado para dentro do seu branch usando merge.

✅ Por que essa opção é “mais simples”?

• 📌 Não reescreve histórico (nada de --force)
• 🤝 Melhor para trabalho em equipe
• 🧯 Menor risco de confusão e perdas

🧭 Quando usar o merge do main no seu branch?

• 🚧 Você ainda está desenvolvendo e quer evitar conflitos grandes depois
• 🧪 Você quer garantir que seu branch funciona com o main mais recente
• 📦 Você vai abrir/atualizar um Merge Request no GitLab

🛠️ Passo a passo (comandos Git)

1) Verifique seu estado atual 🧩

git status

⚠️ Se tiver alterações não commitadas:

• ✅ Recomendado: faça commit (mesmo WIP)
• 🧳 Alternativa: use stash

git add .
git commit -m "WIP: salvando trabalho"

git stash -u

2) Atualize o main local ⬇️

git fetch origin
git checkout main
git pull origin main

3) Volte para seu branch e faça merge do main 🔀

git checkout feature/seu-branch
git merge main

4) Resolva conflitos (se aparecerem) 🧯

Se o Git parar e indicar conflitos:

1. 🔎 Abra os arquivos marcados como conflito
2. ✍️ Escolha o conteúdo correto e remova os marcadores <<<<<<< / ======= / >>>>>>>
3. ✅ Marque como resolvido e finalize

git add .
git commit -m "Merge main no meu branch"

5) Envie seu branch atualizado para o GitLab 🚀

git push

💡 Dica esperta: depois do merge, rode seus testes/local server antes do MR:

python manage.py test
# ou seu comando de testes/lint

✅ Vantagens vs ⚠️ Desvantagens

📌 Comparativo rápido

✅ Vantagens

• 🧾 Histórico preservado (sem reescrever commits)
• 🤝 Menos risco em equipe
• 🚫 Não precisa push --force

⚠️ Desvantagens

• 🌀 Pode criar commits de merge extras
• 📚 Histórico pode ficar menos “linear”

🧷 FAQ rápido

❓ “Eu preciso fazer isso sempre?”
Não sempre — mas é recomendado antes de abrir/atualizar MR ou quando o main mudou bastante.

❓ “E se eu não quiser mexer agora?”
Você pode continuar no seu branch, mas o ideal é integrar o main cedo para evitar conflitos maiores depois.

✅ TL;DR (roteiro rápido)
git fetch origin
git checkout main → git pull origin main
git checkout feature/seu-branch → git merge main
git push

✍️ Post prático para equipes: Merge do main no branch sem reescrever histórico (ideal quando você não quer usar rebase/force push).