Git is the foundation of my code work: versioning, preserving history, and above all separating what is public from what is internal. This page covers the GitHub / GitLab nuance, the value of a self-hosted GitLab, and the repository discipline I apply daily.
GitHub & GitLab — the nuance
| Criterion |  GitHub |  GitLab |
|---|---|---|
| Hosting model | SaaS (cloud) | SaaS or self-hosted (on-premise) |
| Free edition | Cloud offering | Community Edition — open source, self-installable |
| Use in this project | Public · training · portfolio | Internal · professional code |
| Continuous integration | GitHub Actions | Built-in CI/CD pipelines |
| Distinctive strength | Community, visibility | Sovereignty, full control over data |
Why host your own GitLab? Hosting your own GitLab (Community Edition, open source) keeps code and its history outside the cloud: control over access, retention and backups, direct integration with on-premise infrastructure, and consistency with a sovereignty and compliance approach (ISO 27001). GitHub remains ideal for what is meant to be public (portfolio, training); an internal GitLab for what must stay controlled.
Two remotes, two uses
GitHub — public- Portfolio (web deployment)
- Training projects
- Knowledge base (private repository)
Internal GitLab — controlled- Professional code
- History kept internal
- Restricted and traced access
Isolation by architecture: professional code never passes through a public repository. This is not just an organizational rule, it is a structural separation of remotes.
Repository discipline & hygiene
Repository status (audit)
| Project | Remote | Status |
|---|---|---|
| portfolio | GitHub | ✓ Clean |
Identified stray files
| File / folder | Problem | Fix |
|---|---|---|
.idea/ | PyCharm config | git rm -r --cached .idea/ |
.venv/ | Python virtual env | git rm -r --cached .venv/ |
dist/ | PyInstaller build | git rm -r --cached dist/ |
*.lnk | Windows shortcuts | Exclude via .gitignore |
🎯 Key takeaways
- Always create the
.gitignorebefore the firstgit add . - The remote repository keeps a copy of the history pushed to it; project backup and restore must be documented separately
- Store tokens (PAT) in the system's credential manager, never in URLs
- Only one active remote per project; rename
master→main --allow-unrelated-historiesto merge two histories with no common ancestor
💻 First clean commit (workflow)
bash — hygiene + first 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