---
id: KB-INFRA-003
title: Git dual-push para Forgejo lab + mindtek-dev (sem prompt de credenciais)
domain: infrastructure
tags:
  - git
  - forgejo
  - dual-push
  - credentials
  - sync
status: active
severity: medium
created_at: 2026-06-29
updated_at: 2026-06-29
applies_to:
  - knowledge-base
  - any-git-repo-needing-mirror
related_records:
  - KB-INFRA-001
---

# Git dual-push para Forgejo lab + mindtek-dev (sem prompt de credenciais)

## Contexto

Os repositórios do GLPI11 vivem em **dois Forgejos paralelos**:

| Forgejo | URL | Acesso | Uso |
|---|---|---|---|
| **lab** | `git@192.168.100.101:administrador/<repo>.git` (SSH) | Rede local CT100 | Desenvolvimento individual |
| **mindtek-dev** | `https://onmind.mindtek.com.br/git/rodolpho.lopes/<repo>` (HTTPS) | Externo, sem VPN | Equipe da Mindtek tem visibilidade |

Trabalho local é feito no CT100 → push tem que replicar **automaticamente** para mindtek pra equipe ter a mesma visão, sem comandos extras.

SSH no mindtek-dev requer VPN — descartado. Solução: HTTPS com token salvo.

## Padrão: um `git push` empurra pros 2 destinos

### Configuração (uma vez por repo)

```bash
# 1. Credential helper global (uma vez por máquina)
git config --global credential.helper store

# 2. Salva o token HTTPS em ~/.git-credentials (uma vez por host)
echo "https://<user>:<TOKEN>@onmind.mindtek.com.br" >> ~/.git-credentials
chmod 600 ~/.git-credentials

# 3. Configura origin com 2 URLs de push (por repo)
cd /caminho/do/repo
git remote set-url --add --push origin "git@192.168.100.101:administrador/<repo>.git"
git remote set-url --add --push origin "https://onmind.mindtek.com.br/git/rodolpho.lopes/<repo>.git"
```

### Resultado esperado

```
$ git remote -v
origin  git@192.168.100.101:administrador/<repo>.git (fetch)
origin  git@192.168.100.101:administrador/<repo>.git (push)
origin  https://onmind.mindtek.com.br/git/rodolpho.lopes/<repo>.git (push)
```

### Uso diário

```bash
git add ...
git commit -m "..."
git push                # ← empurra pros DOIS forgejos sequencialmente
```

`git pull` / `git fetch` lê apenas do **lab** (mais rápido na CT100). Mudanças vindas da equipe pelo mindtek-dev precisam de fetch manual:
```bash
git fetch https://onmind.mindtek.com.br/git/rodolpho.lopes/<repo>.git main
```

Mas como o workflow é "trabalho local → push pra ambos", o lab sempre tem a versão mais recente; mindtek é só espelho.

## Criar um repo novo no mindtek-dev (via API)

```bash
TOKEN="..."
curl -s -X POST -H "Authorization: token $TOKEN" -H "Content-Type: application/json" \
  "https://onmind.mindtek.com.br/git/api/v1/user/repos" \
  -d '{
    "name": "<repo>",
    "description": "...",
    "private": false,
    "auto_init": false,
    "default_branch": "main"
  }'
```

Resposta inclui `clone_url` (HTTPS) e `ssh_url`.

## Gotchas

### 1. `--add --push` mantém ordem importante

Se você esquecer de adicionar o URL do lab como push (só rodar `--add --push` com mindtek), git considera que o pushurl é apenas o mindtek — push pra lab **não acontece** mesmo sendo o fetch URL.

**Regra:** sempre adicione AMBOS explicitamente com `--add --push`, mesmo o que já é fetch URL.

### 2. Falha em uma URL não para a outra

Git tenta os pushURLs em sequência. Se a 1ª falhar (ex: lab caiu), git **continua** pra 2ª. Mas o exit code do `git push` reflete a soma — falha em qualquer um retorna erro.

Pra investigar: olha o output do `git push` que mostra cada destino separadamente.

### 3. `~/.git-credentials` é texto plano

Tem permissão 600 (só o owner lê), mas em backup/snapshot do disco vaza. Em ambientes com múltiplos usuários, prefira `credential.helper cache --timeout=3600` (memória, não disco).

### 4. Token expirou? Não dá erro óbvio

Push HTTPS falha com mensagem de "fatal: Authentication failed". Resolva editando `~/.git-credentials`:
```bash
sed -i 's|:OLD_TOKEN@|:NEW_TOKEN@|' ~/.git-credentials
```

Ou apague a linha do host e o git pede o novo token no próximo push (e salva).

### 5. Token comprometido — como revogar

1. `https://onmind.mindtek.com.br/git/user/settings/applications` → revoga
2. Apaga a linha do host no `~/.git-credentials`
3. Cria novo token e re-adiciona

## Replicar config em outro repo

Como `credential.helper=store` é global, qualquer repo que aponte pra `onmind.mindtek.com.br` herda o token sem reconfigurar. Pra adicionar dual-push:

```bash
cd /caminho/outro/repo
git remote set-url --add --push origin <URL_LAB>
git remote set-url --add --push origin <URL_MINDTEK>
```

Ou crie um alias de shell se for fazer várias vezes:
```bash
alias git-dualpush='_f() {
  git remote set-url --add --push origin "git@192.168.100.101:administrador/$1.git"
  git remote set-url --add --push origin "https://onmind.mindtek.com.br/git/rodolpho.lopes/$1.git"
}; _f'

# Uso:
git-dualpush knowledge-base
```

## Aplicado em

- `/opt/projects/GLPI11/knowledge-base` (validado em 2026-06-29)

## Lições

1. **Múltiplos pushURLs no mesmo remote** > múltiplos remotes separados — não precisa lembrar de `git push lab && git push mindtek`.
2. **Credential helper store** é o caminho mais simples pra HTTPS sem prompt, desde que o `~/.git-credentials` esteja com perms 600 e não vá pra backup público.
3. **Fetch fica num único destino** — espelhamento via push é unidirecional. Pra puxar mudanças do mirror, fetch manual da URL.
4. **Token no URL embutido funciona mas vaza** em `git remote -v` — sempre prefira credential helper a `https://user:pass@host/...`.