Git est le socle de mon travail de code : versionner, sauvegarder l'historique, et surtout cloisonner
ce qui est public de ce qui est interne. Cette page présente la nuance GitHub / GitLab,
l'intérêt d'un GitLab auto-hébergé, et la discipline de dépôts que j'applique au quotidien.
GitHub & GitLab — la nuance
| Critère |  GitHub |  GitLab |
|---|---|---|
| Modèle d'hébergement | SaaS (cloud) | SaaS ou auto-hébergé (on-premise) |
| Édition libre | Offre cloud | Community Edition — open source, installable chez soi |
| Usage dans ce projet | Public · formation · portfolio | Interne · code professionnel |
| Intégration continue | GitHub Actions | Pipelines CI/CD intégrés |
| Atout distinctif | Communauté, visibilité | Souveraineté, contrôle total des données |
Pourquoi un GitLab à soi ? Héberger son propre GitLab (Community Edition, open source) garde
le code et son historique hors du cloud : maîtrise des accès, de la rétention et des sauvegardes,
intégration directe à une infrastructure on-premise, et cohérence avec une démarche de souveraineté
et de conformité (ISO 27001). GitHub reste idéal pour ce qui a vocation à être public (portfolio, formation) ;
un GitLab interne pour ce qui doit rester maîtrisé.
Deux remotes, deux usages
GitHub — public- Portfolio (déploiement web)
- Projets de formation
- Base de connaissances (dépôt privé)
GitLab interne — maîtrisé- Code professionnel
- Historique conservé en interne
- Accès restreint et tracé
Étanchéité par l'architecture : le code professionnel ne transite jamais par un
dépôt public. Ce n'est pas seulement une consigne d'organisation, c'est une séparation structurelle des remotes.
Discipline & hygiène de dépôts
État des dépôts (audit)
| Projet | Remote | Statut |
|---|---|---|
| portfolio | GitHub | ✓ Propre |
Fichiers parasites identifiés
| Fichier / dossier | Problème | Correction |
|---|---|---|
.idea/ | Config PyCharm | git rm -r --cached .idea/ |
.venv/ | Env. virtuel Python | git rm -r --cached .venv/ |
dist/ | Build PyInstaller | git rm -r --cached dist/ |
*.lnk | Raccourcis Windows | Exclure via .gitignore |
🎯 Ce qu'il faut retenir
- Toujours créer le
.gitignoreavant le premiergit add . - Le dépôt distant conserve une copie de l'historique qui y a été poussé ; la sauvegarde et la restauration du projet doivent être documentées séparément
- Stocker les tokens (PAT) dans le gestionnaire d'identifiants du système, jamais dans les URLs
- Un seul remote actif par projet ; renommer
master→main --allow-unrelated-historiespour fusionner deux historiques sans ancêtre commun
💻 Premier commit propre (workflow)
bash — hygiène + premier 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