Configuration Git sous Windows avec GitLab interne, SSO, PAT et VS Code

Cette procédure décrit la configuration d'un poste Windows pour travailler avec GitLab Self-Managed interne de La Poste depuis Git Bash et Visual Studio Code.

1. Environnement cible

Élément	Valeur
GitLab	`https://gitlab.pop.sf.intra.laposte.fr`
Groupe principal	`caas`
Authentification GitLab Web	SSO
Authentification Git	Personal Access Token (PAT)
Protocole Git	HTTPS
Gestionnaire d'identifiants	Git Credential Manager (GCM)
IDE	Visual Studio Code

2. Principe général

Le SSO utilisé pour se connecter à GitLab dans le navigateur et l'authentification utilisée par Git ne sont pas nécessairement les mêmes.

Navigateur
    |
    +--> SSO La Poste
    |
    +--> GitLab


Git / VS Code
    |
    +--> HTTPS
    |
    +--> Git Credential Manager
    |
    +--> Personal Access Token
    |
    +--> GitLab

Avec Git over HTTPS, GitLab utilise le Personal Access Token comme mot de passe. Lorsqu'un compte utilise SAML/SSO ou 2FA, un PAT peut être nécessaire pour les opérations Git HTTPS. citeturn0search0

3. Pré-requis

Un compte GitLab actif.
Un accès SSO La Poste permettant d'accéder à GitLab.
Les droits nécessaires sur les projets GitLab à utiliser.
Git installé sous Windows.
Git Credential Manager installé.
Visual Studio Code installé.

4. Créer un Personal Access Token GitLab

4.1 Accéder à la gestion des tokens

Se connecter à GitLab avec le SSO puis ouvrir :

Avatar
  |
  +--> Edit profile
        |
        +--> Access
              |
              +--> Personal access tokens

GitLab documente actuellement ce chemin pour créer un Personal Access Token. citeturn0search0

4.2 Créer le token

Exemple de configuration :

Champ	Valeur recommandée
Token name	`VS Code - Windows`
Expiration date	Selon la politique de l'organisation
Scope	`write_repository`

4.3 Scope nécessaire

Pour les opérations Git classiques :

clone
fetch
pull
push

le scope write_repository donne les droits de lecture et d'écriture nécessaires sur les repositories accessibles au token. citeturn0search3

Il n'est pas nécessaire de donner le scope api uniquement pour effectuer des opérations Git.

4.4 Sauvegarder le token

ATTENTION : le Personal Access Token est une donnée secrète. Ne jamais le transmettre par email, chat, ticket ou dépôt Git.

Le token complet n'est généralement affiché qu'au moment de sa création. Il faut donc le conserver dans un gestionnaire de secrets/mots de passe approprié si nécessaire. citeturn0search0

5. Vérifier Git sous Windows

Ouvrir Git Bash ou le terminal intégré de Visual Studio Code.

Vérifier la version de Git :

git --version

Exemple :

git version 2.49.0.windows.1

6. Vérifier Git Credential Manager

Git Credential Manager permet à Git de gérer les informations d'authentification sans avoir à stocker manuellement un token dans un fichier texte.

Vérifier sa version :

git credential-manager --version

Exemple :

2.6.1+786ab03440ddc82e807a97c0e540f5247e44cec6

Vérifier le diagnostic :

git credential-manager diagnose

Un résultat avec Credential storage [ OK ] indique notamment que le stockage des credentials est fonctionnel.

7. Vérifier que Git utilise Git Credential Manager

Exécuter :

git config --show-origin --get-all credential.helper

Résultat attendu :

file:C:/Program Files/Git/etc/gitconfig manager

Cela signifie que Git utilise Git Credential Manager.

Il n'est donc pas nécessaire de créer manuellement un fichier .gitcredentials.

8. Ne pas créer manuellement .gitcredentials

La configuration recommandée est d'utiliser Git Credential Manager plutôt que de stocker le Personal Access Token directement dans un fichier texte.

À éviter :

~/.git-credentials

avec un contenu contenant directement le token.

Bonne pratique : laisser Git Credential Manager gérer les credentials.

Le stockage via Git Credential Manager évite notamment de devoir inscrire le token directement dans les URLs Git ou dans des scripts. citeturn0search6

9. Configurer l'identité Git

Le nom et l'adresse email Git servent à identifier l'auteur des commits. Ils ne correspondent pas directement au mot de passe ou au token GitLab.

9.1 Vérifier la configuration actuelle

git config --global user.name
git config --global user.email

9.2 Configurer le nom

git config --global user.name "Prénom Nom"

9.3 Configurer l'adresse email

git config --global user.email "prenom.nom@laposte.fr"

Utiliser de préférence l'adresse email professionnelle reconnue par GitLab.

10. Récupérer l'URL HTTPS d'un repository

Dans GitLab :

Projet
  |
  +--> Code
        |
        +--> Clone
              |
              +--> HTTPS

Une URL de repository ressemble à :

https://gitlab.pop.sf.intra.laposte.fr/caas/mon-projet.git

11. Cloner un repository

Se positionner dans le répertoire destiné à accueillir les repositories.

Exemple :

cd ~/OneDrive\ -\ LA\ POSTE\ GROUPE/Documents/LBP/Github

Cloner le repository :

git clone https://gitlab.pop.sf.intra.laposte.fr/caas/mon-projet.git

IMPORTANT : ne jamais mettre le Personal Access Token directement dans l'URL de la commande.

Cela pourrait notamment exposer le token dans l'historique du shell. GitLab recommande de saisir le token lorsqu'il est demandé plutôt que de l'inclure directement dans l'URL. citeturn0search0

12. Première authentification Git

Lors du premier accès au repository, Git Credential Manager peut ouvrir une fenêtre d'authentification.

Lorsque Git demande les informations :

Champ	Valeur
Username	`XIOE341`
Password	Personal Access Token

Le Personal Access Token est utilisé comme mot de passe pour Git over HTTPS. citeturn0search0

Attention : le champ Password doit contenir le PAT, et non le mot de passe SSO.

13. Vérifier le repository cloné

Entrer dans le repository :

cd mon-projet

Afficher les remotes :

git remote -v

Résultat attendu :

origin  https://gitlab.pop.sf.intra.laposte.fr/caas/mon-projet.git (fetch)
origin  https://gitlab.pop.sf.intra.laposte.fr/caas/mon-projet.git (push)

14. Tester le pull

git pull

Si le repository est déjà à jour :

Already up to date.

Si des modifications existent sur GitLab, Git les récupère dans le repository local.

15. Workflow Git quotidien

15.1 Récupérer les dernières modifications

git pull

15.2 Vérifier l'état du repository

git status

15.3 Ajouter les modifications

Ajouter un fichier :

git add fichier.txt

Ajouter toutes les modifications :

git add .

15.4 Créer un commit

git commit -m "Description de la modification"

15.5 Envoyer les modifications vers GitLab

git push

16. Workflow complet

Le workflow classique est donc :

# 1. Récupérer les modifications distantes
git pull

# 2. Vérifier les modifications locales
git status

# 3. Ajouter les fichiers
git add .

# 4. Créer le commit
git commit -m "Description de la modification"

# 5. Envoyer vers GitLab
git push

17. Utilisation avec Visual Studio Code

Visual Studio Code utilise directement Git installé sur le poste. Il n'est donc pas nécessaire d'installer un deuxième Git uniquement pour VS Code.

17.1 Ouvrir le repository

Depuis Git Bash :

cd ~/OneDrive\ -\ LA\ POSTE\ GROUPE/Documents/LBP/Github/mon-projet
code .

Le repository est alors ouvert dans Visual Studio Code.

17.2 Source Control

Dans VS Code, sélectionner l'icône Source Control dans la barre latérale gauche.

Les fichiers modifiés apparaissent dans la section Changes.

17.3 Stage / git add

Cliquer sur le bouton + à côté d'un fichier pour effectuer :

git add fichier

L'équivalent de git add . est l'action permettant de stage toutes les modifications.

17.4 Commit

Entrer le message de commit dans le champ prévu à cet effet puis sélectionner Commit.

Équivalent terminal :

git commit -m "Description de la modification"

17.5 Pull

Le pull peut être effectué depuis le menu Source Control ou le menu Git de VS Code.

Équivalent terminal :

git pull

17.6 Push

Le push peut être effectué via Push ou Sync Changes, selon la version de VS Code.

Équivalent terminal :

git push

18. Résumé des correspondances VS Code / Git

Action VS Code	Commande Git
Pull	`git pull`
Stage fichier	`git add fichier`
Stage all	`git add .`
Commit	`git commit -m "..."`
Push	`git push`
Afficher les modifications	`git status`

19. Plusieurs repositories

Un même Personal Access Token peut être utilisé pour plusieurs repositories auxquels le compte dispose des droits nécessaires.

Exemple d'organisation locale :

Github/
├── projet-a/
├── projet-b/
├── projet-c/
├── projet-d/
└── projet-e/

Chaque repository possède son propre répertoire .git.

Il n'est pas nécessaire de créer manuellement ces répertoires .git : ils sont créés automatiquement par git clone ou git init.

20. Fichiers à ne pas créer manuellement

Élément	Action
`.git`	Ne pas créer manuellement. Créé automatiquement dans chaque repository.
`.gitcredentials`	Ne pas créer manuellement. Utiliser Git Credential Manager.

21. Vérification complète de la configuration

Les commandes suivantes permettent de contrôler la configuration :

# Version Git
git --version

# Version Git Credential Manager
git credential-manager --version

# Diagnostic GCM
git credential-manager diagnose

# Credential helper utilisé
git config --show-origin --get-all credential.helper

# Identité Git
git config --global user.name
git config --global user.email

# Remote du repository
git remote -v

# Etat du repository
git status

22. Exemple de configuration fonctionnelle

Une configuration fonctionnelle peut présenter les éléments suivants :

Git
    version : 2.49.0.windows.1

Git Credential Manager
    version : 2.6.1

credential.helper
    manager

GitLab
    https://gitlab.pop.sf.intra.laposte.fr

Authentification
    SSO pour l'accès Web
    PAT pour Git HTTPS

PAT
    scope : write_repository

Git username
    XIOE341

23. Dépannage

23.1 Git demande le login et le token à chaque pull

Vérifier que Git Credential Manager est configuré :

git config --show-origin --get-all credential.helper

Le résultat doit notamment contenir :

manager

Vérifier également :

git credential-manager diagnose

23.2 Le token est refusé

Vérifier :

que le token n'est pas expiré ;
que le token n'est pas révoqué ;
que le scope write_repository est présent ;
que le compte possède les droits nécessaires sur le repository ;
que l'URL du remote pointe bien vers le GitLab interne ;
que le token est utilisé comme mot de passe et non le mot de passe SSO.

23.3 Vérifier l'URL du remote

git remote -v

L'URL doit utiliser HTTPS et le domaine GitLab interne :

https://gitlab.pop.sf.intra.laposte.fr/...

23.4 Le repository fonctionne en lecture mais pas en push

Vérifier le scope du token.

write_repository

Le scope read_repository permet la lecture, tandis que write_repository permet la lecture et l'écriture via Git over HTTP. citeturn0search3

24. Sécurité

Ne jamais communiquer un Personal Access Token.
Ne jamais l'inscrire dans un script en clair.
Ne jamais le mettre directement dans une URL Git.
Ne jamais le committer dans un repository.
Utiliser une date d'expiration adaptée à la politique de sécurité.
Utiliser le scope minimal nécessaire.
Révoquer immédiatement un token suspect ou compromis.

25. Extension GitLab pour VS Code

L'utilisation de Git avec VS Code ne nécessite pas obligatoirement l'extension GitLab for VS Code.

Pour les opérations classiques :

pull
add
commit
push

Git + Git Credential Manager + VS Code suffisent.

L'extension GitLab peut cependant être utilisée pour bénéficier de fonctions supplémentaires liées à GitLab, comme les issues, merge requests et autres fonctionnalités d'intégration.

Dans ce cas, consulter la politique interne et la documentation GitLab concernant les scopes supplémentaires requis par l'extension avant de créer un token dédié.

26. Architecture finale recommandée

                         ┌─────────────────────────────┐
                         │  GitLab La Poste            │
                         │                             │
                         │  gitlab.pop.sf.intra...     │
                         └──────────────┬──────────────┘
                                        │
                                  HTTPS / Git
                                        │
                                        ▼
                         ┌─────────────────────────────┐
                         │ Git Credential Manager      │
                         │                             │
                         │ Authentification sécurisée  │
                         └──────────────┬──────────────┘
                                        │
                                        ▼
                         ┌─────────────────────────────┐
                         │ Windows                     │
                         │                             │
                         │ Credentials sécurisés       │
                         └──────────────┬──────────────┘
                                        │
                                        ▼
                         ┌─────────────────────────────┐
                         │ Git / VS Code               │
                         │                             │
                         │ pull                        │
                         │ add                         │
                         │ commit                      │
                         │ push                        │
                         └─────────────────────────────┘

27. Workflow recommandé au quotidien

Avant de commencer :

    git pull


Pendant le travail :

    modifier les fichiers


Avant le commit :

    git status


Ajouter les modifications :

    git add .


Créer le commit :

    git commit -m "Description claire de la modification"


Envoyer vers GitLab :

    git push

28. Références

GitLab Documentation — Personal Access Tokens
GitLab Documentation — Access Token Scopes
GitLab Documentation — Clone a Git repository
Git Credential Manager — GitLab support

Résumé : pour ce poste, la configuration recommandée est Git HTTPS + Personal Access Token avec write_repository + Git Credential Manager + Visual Studio Code. Aucun fichier .gitcredentials ne doit être créé manuellement.