Astuces Git Comment stocker sur Windows les données d’identification pour différents comptes sur une même forge logicielle (GitLab/Framagit/Github) Lorsqu’on clone en https un dépôt privé depuis une forge logicielle, le nom d’utilisateur et le mot de passe sont requis. Une fois saisis, ceux-ci sont sauvegardés dans le gestionnaire d’identification par l’intermédiaire du “Git Credential Manager Core” (→ GCM) si l’option est sélectionnée lors de l’installation de Git for Windows. Le problème est que lorqu’on possède plusieurs comptes sur la même forge logicielle, Git utilisera toujours l’unique jeu de données d’identification enregistré lors de la 1ère authentification sur le site. Ainsi, il n’est plus possible de cloner/pusher un dépôt privé appartenant à un 2ème compte. Plusieurs solutions sont alors possibles Solution n°1 : Réinitialiser les données d’identification enregistrées à chaque connexion depuis un autre compte Effacer les données d’identification enregistrées pour la forge logicielle, de façon à ce que le GCM demande à nouveau de s’identifier. Pour cela : S’assurer que l’identification est bien géré par GCM : $ git config credential.helper manager-core (1) 1 manager-core correspond au “Git Credential Manager Core” Ouvrir le gestionnaire d’identification Windows (→ Démarrer Gestionnaire d’identification) Effacer l’entrée associée à la forge logicielle Solution n°2 : Mettre en place une politique d’identification liée à chaque dépôt Demander à GCM de mémoriser les données d’identification pour chaque dépôt et non pour la forge logicielle entière. Pour cela : S’assurer que l’identification est bien géré par GCM : $ git config credential.helper manager-core (1) 1 manager-core correspond au “Git Credential Manager Core” Configurer GCM pour qu’il enregistre les données d’identification pour chaque dépôt $ $ git config --global credential.useHttpPath true À ce stade, le gestionnaire d’identification devrait posséder une entrée pour chaque dépôt après une 1ère identification 🕮 Source : How to store credentials for two different github accounts? ''' Solution n°3 : passer par SSH Passer par SSH à travers le protocole git. Voir GitLab and SSH keys pour une mise en œuvre sur GitLab/Framagit. Comment prendre en charge les liens symboliques avec Git sous Windows ? Les liens symboliques sont une fonctionnalité plutôt récente sous Windows. Les liens symboliques ne fonctionnent que sur les sytèmes de fichier NTFS et pas FAT ou exFAT. Voir Symbolic Links sur le wiki du projet “Git for Windows” Sous Windows 10, la création de liens symboliques se fait nativement avec avec la commande mklink dans une console exécutée en tant qu’administrateur. Pour éviter d’avoir à ouvrir la console en tant qu’administrateur, on peut également attribuer à l’utilisateur courant le droit “Créer des liens symboliques” en modifiant la stratégie de sécurité locale. Pour cela : ouvrir l’outil d’administration “Statégie de sécurité locale” Panneau de configuration Système et sécurité Outils d’administration) ajouter l’utilisateur courant dans l’attribut “Créer des liens symboliques” Paramètres de sécurité Stratégies locales Attribution des droits d’utilisateur Créer des liens symboliques La création de liens symboliques peut également se faire de manière graphique grâce à l’outil Link Shell Extension . La prise en charge des liens symboliques par Git au sein d’un dépôt logiciel peut alors se faire normalement sous 2 conditions : elle doit avoir été activée : soit au niveau système, lors de l’installation ou via la commande : git config --system core.symlinks true soit au niveau global : git config --global core.symlinks true soit au niveau local git config --local core.symlinks true Pour savoir si la fonctionnalité est activée et déterminer sa portée actuelle ainsi que l’emplacement où sa configuration a été faite, on peut utiliser la commande : git config --show-scope --show-origin core.symlinks Exemple : $ git config --show-scope --show-origin core.symlinks global file:C:/Users/claud/.gitconfig true les liens symboliques doivent cibler des fichiers appartenant au même dépôt à l’aide de chemins relatifs (et non absolus). La 2ème condition est remplie lorsqu’on fourni un chemin relatif à la commande mklink ou lorsqu’on crée un lien symbolique avec l’outil Link Shell Extension avec sa configuration par défaut (accessible avec l’application “LSEConfig”) 🕮 Sources : Symlinks in Windows Git symbolic links in Windows Symbolic Links Utiliser WinMerge comme interface pour git diff 2 actions sont à entreprendre : Installer WinMerge Modifier la configuration de Git $ # Configuration pour `git difftool` $ git config --global diff.tool winmerge (1) $ git config --global difftool.winmerge.cmd "\"\$PROGRAMFILES\"/WinMerge/WinMergeU.exe -r -u -e -dl \"Local\" -dr \"Remote\" \"\$LOCAL\" \"\$REMOTE\"" (2) $ git config --global difftool.prompt false (3) $ # Configuration pour `git mergetool` $ git config --global merge.tool winmerge $ git config --global mergetool.prompt false $ git config --global mergetool.winmerge.trustExitCode true (4) $ git config --global mergetool.winmerge.cmd "\"\$PROGRAMFILES\"/WinMerge/WinMergeU.exe -r -u -e -dl \"Local\" -dr \"Remote\" \"\$LOCAL\" \"\$REMOTE\" \"\$BASE\" \"\$MERGED\"" 1 Utilise WinMerge comme outil tierce de comparaison pour la commande git difftool 2 Demande à WinMerge de comparer de manière récursive (→ -r) les chemins fournis par git difftool dans les variables $LOCAL et $REMOTE et affiche le résultat dans 2 fenêtres dont les titres sont “Local” et “Remote” (→ -dl et -dr) sans mettre à jour la liste des fichiers ou dossiers récents (→ -u) et permet de quitter WinMerge uniquement avec la touche Esc (→ -e) 3 Ne demande pas confirmation à chaque invocation de l’outil externe 4 Indique à git mergetool que l’outil tierce de fusion indique le succès d’une résolution de fusion avec son code de sortie. (Dans le cas contraire, git mergetool invite l’utilisateur à indiquer la réussite ou l’échec de la fusion) Ensuite, on peut utiliser git difftool -d pour comparer : la copie de travail et l’index → git difftool -d l’index et le dernier commit → git difftool -d --cached HEAD 2 branches (ex. : main et develop) → git difftool -d main develop les 2 derniers commits → git difftool -d HEAD HEAD~1 … L’option -d demande à git difftool de copier les fichiers modifiés dans un répertoire temporaire avant de lancer l’outil de comparaison tierce. Ceci a pour conséquence de lancer une comparaison de répertoires plutôt qu’une comparaison de fichiers et évite donc, dans notre cas, une nouvelle exécution de WinMerge à chaque comparaison de fichier. 🕮 Sources : How do I view 'git diff' output with my preferred diff tool/ viewer? Use Winmerge inside of Git to file diff Mettre en place un workflow pour des expérimentations Voir A Git workflow for code experiments 🞄 🞄 🞄 Git Git