Git es la base de mi trabajo con código: versionar, conservar el historial y, sobre todo, separar lo público de lo interno. Esta página presenta el matiz GitHub / GitLab, el interés de un GitLab autoalojado, y la disciplina de repositorios que aplico a diario.
GitHub y GitLab — el matiz
| Criterio |  GitHub |  GitLab |
|---|---|---|
| Modelo de alojamiento | SaaS (nube) | SaaS o autoalojado (on-premise) |
| Edición libre | Oferta en la nube | Community Edition — open source, instalable en casa |
| Uso en este proyecto | Público · formación · portfolio | Interno · código profesional |
| Integración continua | GitHub Actions | Pipelines CI/CD integrados |
| Ventaja distintiva | Comunidad, visibilidad | Soberanía, control total de los datos |
¿Por qué tener tu propio GitLab? Alojar tu propio GitLab (Community Edition, open source) mantiene el código y su historial fuera de la nube: control de accesos, retención y copias de seguridad, integración directa con una infraestructura on-premise, y coherencia con un enfoque de soberanía y cumplimiento (ISO 27001). GitHub sigue siendo ideal para lo que está destinado a ser público (portfolio, formación); un GitLab interno para lo que debe permanecer controlado.
Dos remotos, dos usos
GitHub — público- Portfolio (despliegue web)
- Proyectos de formación
- Base de conocimiento (repositorio privado)
GitLab interno — controlado- Código profesional
- Historial conservado internamente
- Acceso restringido y trazado
Aislamiento por arquitectura: el código profesional nunca transita por un repositorio público. No es solo una norma de organización, es una separación estructural de los remotos.
Disciplina e higiene de repositorios
Estado de los repositorios (auditoría)
| Proyecto | Remoto | Estado |
|---|---|---|
| portfolio | GitHub | ✓ Limpio |
Archivos parásitos identificados
| Archivo / carpeta | Problema | Corrección |
|---|---|---|
.idea/ | Configuración de PyCharm | git rm -r --cached .idea/ |
.venv/ | Entorno virtual de Python | git rm -r --cached .venv/ |
dist/ | Build de PyInstaller | git rm -r --cached dist/ |
*.lnk | Accesos directos de Windows | Excluir mediante .gitignore |
🎯 Lo que hay que recordar
- Crear siempre el
.gitignoreantes del primergit add . - El repositorio remoto conserva una copia del historial que se le ha enviado; la copia de seguridad y la restauración del proyecto deben documentarse por separado
- Guardar los tokens (PAT) en el gestor de credenciales del sistema, nunca en las URLs
- Un único remoto activo por proyecto; renombrar
master→main --allow-unrelated-historiespara fusionar dos historiales sin ancestro común
💻 Primer commit limpio (workflow)
bash — higiene + primer push
# 1. .gitignore avant tout # .venv/ __pycache__/ .idea/ dist/ build/ *.spec .env *.lnk # 2. Nettoyer le staging si des parasites ont été indexés git rm -r --cached .idea/ .venv/ dist/ # 3. Branche principale + premier commit git branch -m master main git add . git commit -m "feat: initial commit" # 4. Remote (token dans le gestionnaire d'identifiants) git config --global credential.helper manager git remote add origin https://<gitlab-interne>/<utilisateur>/PROJET.git git push -u origin main # 5. Si le remote a déjà un commit initial (README auto) git pull origin main --allow-unrelated-histories git push -u origin main
Python
Automatisation
Obsidian