Utilisation d'OASIS-SVN et de git pour le contrôle du code source d'accès

REMARQUE : Je parlerai de ce sujet en profondeur dans le prochain webinaire mensuel Access et SQL Server le 9 juillet à 18h30 CDT. Inscrivez-vous pour voir le processus en direct et poser des questions !

Comme nous travaillons avec plusieurs applications et parfois en équipe, le contrôle du code source est assez important pour gérer les changements. Nous en sommes venus à aimer utiliser git pour nos projets. À l'origine, utiliser git avec Access serait un défi, mais grâce à un complément nommé OASIS-SVN, nous pouvons utiliser efficacement git avec des projets Access pour gérer les modifications.

Pourquoi utiliser le contrôle du code source ? Vous ne pouvez pas simplement le fermer ?

L'objectif principal derrière le contrôle du code source est de pouvoir répondre facilement à whodunit.

C'est particulièrement important lorsque vous avez affaire à un rapport de bogue et qu'on vous rappelle que vous avez déjà vu quelque chose de similaire et que vous pensiez que vous l'aviez peut-être corrigé, mais que le client le signale toujours. Cependant, lorsque le bogue a été "corrigé" il y a six mois, il pourrait aussi bien s'agir d'un tout nouveau bogue car nous avons déjà oublié le correctif que nous avons mis en place il y a 6 mois. Je ne sais pas pour vous, mais la perspective de fouiller dans un tas de sauvegardes compressées ne semble pas très… détectable.

Placer vos modifications dans un contrôle de code source demande de la discipline, mais facilitera grandement la révision et la gestion des modifications. Vous pouvez facilement rechercher l'historique et voir exactement ce qui change.

Un autre scénario consiste à déterminer ce qui a exactement changé. Si vous avez apporté plusieurs modifications et que vous devez les revoir avant de pousser une nouvelle version, c'est là que le contrôle du code source vous aide. Vous avez la possibilité de vérifier votre travail et de vous assurer que vous avez fait tout ce que vous aviez prévu de faire. Plus de "je pense que je l'ai déjà fait". seulement pour se faire dire par le client que vous avez oublié ce petit détail que le client vous a demandé la semaine dernière. De plus, cela permet à l'équipe de faire des revues de code pour les autres; nous pouvons examiner le travail des autres, fournir des commentaires et nous entraider pour maintenir un haut niveau de qualité.

Pourquoi git ? Access fonctionne avec Visual SourceSafe, n'est-ce pas ?

Dans les versions antérieures à Access 2013, Access prenait en charge le contrôle du code source de manière native, mais il le faisait à l'aide d'une spécification Microsoft propriétaire, MSSCCI. Pour aggraver les choses, la spécification suppose un modèle de check-out/check-in qui donne aux développeurs un verrou exclusif sur les objets sur lesquels ils travaillent. De plus, les tableaux de l'application Access étaient essentiellement une grosse goutte qui ne pouvait pas être lue et encore moins examinée.

En pratique, un tel modèle est très lourd à utiliser même dans une petite équipe. L'un des principaux problèmes est qu'une demande de modification est rarement confirmée pour un seul objet ; les développeurs peuvent avoir besoin de toucher plus qu'une poignée d'objets et ainsi, les collisions peuvent être inévitables, en particulier pour les modules principaux/partagés.

Git évite toute la laideur que nous voyons avec l'ancien modèle de check-out/check-in, mais cela nécessite une philosophie différente dans la gestion des changements. Au lieu de vérifier quelque chose, nous travaillons simplement à partir d'une branche et lorsque nous en avons terminé, nous la fusionnons dans la branche principale. On peut avoir plusieurs branches en parallèle si on le souhaite bien qu'en pratique, on n'ait besoin que de 2 ou 3 branches parallèles; un pour représenter la version de production ; un autre pour le développement et peut-être un troisième pour les corrections de bogues critiques. Cela peut être fait avec un projet Access, et devrait l'être. Sinon, il peut être très difficile de garder une trace de ce qui se passe dans le fichier de production, en particulier pour les applications non triviales.

Une excellente ressource pour apprendre git peut être trouvée ici; il a un bac à sable pour que vous puissiez jouer. Si vous êtes comme moi et que vous aimez manger des morceaux de viande et que vous savez comment cela fonctionne, c'est une bonne ressource.

Enfin, arrêtez d'utiliser déjà Visual SourceSafe. Il est bogué, susceptible de perdre vos données et n'est plus pris en charge depuis _years_, pas même par Access depuis 2013.

Mais si Access 2013+ ne prend plus en charge le contrôle du code source, comment pourrions-nous encore l'avoir ? ! ?

Parce qu'OASIS-SVN n'est pas un fournisseur MSSCCI mais juste un simple complément d'accès. Il existe d'autres compléments Access similaires (par exemple Ivercy par exemple) qui contournent la limitation. Dans tous les cas, ces compléments utilisent intensivement exactement les mêmes méthodes non documentées qu'Access a utilisées en interne pour le contrôle du code source ; Application.SaveAsText et Application.LoadFromText . Ces méthodes sont toujours présentes dans la version actuelle d'Access. En aparté, il y a un élément UV pour le documenter pour assurer la continuité. OASIS-SVN continue de bien fonctionner même avec la version Access actuelle.

Pourquoi continuez-vous à parler d'OASIS-SVN et de git ? Puis-je utiliser l'un ou l'autre ?

Il est important de comprendre que les deux outils sont complémentaires et que vous avez besoin des deux. Vous voyez, la raison pour laquelle vous avez besoin d'OASIS-SVN est de vous faciliter le plus possible le travail acharné et de les représenter comme un tas de fichiers texte, plutôt que de les avoir à l'intérieur d'un gros blob d'un fichier binaire qui est le Fichier ACCD*. Il n'est pas logique que le fichier ACCDB soit contrôlé par le code source, car il n'aurait pas un historique des modifications approprié et serait en grande partie illisible. Ainsi, OASIS-SVN est l'outil pour créer les fichiers texte qui peuvent être utilisés pour reconstruire votre application Access, et c'est le travail de git de coder ces fichiers à la source. Le git ne peut pas et ne doit pas fonctionner avec le fichier ACCDB.

Si vous êtes nouveau sur git, vous avez une étape supplémentaire par rapport à ce que les autres font habituellement sur leurs projets Visual Studio car vous travaillez avec un fichier binaire, pas un ensemble réel de dossiers avec un tas de fichiers texte avec des extensions amusantes. Vous devrez donc prendre l'habitude d'exporter/importer systématiquement vos modifications entre le fichier ACCDB et les fichiers texte qui composent votre dépôt git.

Prérequis

Pour commencer, nous avons besoin de 3 logiciels :

1. Git pour Windows
2. TortoiseGit
3. OASIS-SVN

À proprement parler, vous n'avez pas besoin des 2e et 3e logiciels. Vous pourriez en fait vous contenter du premier, mais le gros inconvénient est que vous devrez exporter/importer manuellement en écrivant votre propre module VBA pour le faire et croyez-moi, c'est beaucoup de travail pour des raisons qui deviendront plus claires au fur et à mesure nous suivons. Ainsi, OASIS-SVN est fortement recommandé. Vous n'avez pas non plus besoin d'avoir TortoiseGit, mais j'aime vraiment avoir une interface graphique pour faciliter le travail. Cela peut offenser certains puristes de la ligne de commande qui vous diront que vous devez simplement utiliser git dans une ligne de commande, et non via une jolie interface graphique. Cependant, je l'aime paresseux et rapide et la plupart du temps, le processus est simple car il est plus rapide pour moi d'exécuter une commande à partir d'un menu que d'ouvrir un shell bash et de taper une commande. Cela dit, TortoiseGit n'est en réalité qu'un fin wrapper sur les commandes git, vous devriez donc faire très attention à la commande git qu'il exécute et à ce qu'elle signifie.

Installez-les tous; Je me référerai à leurs sites Web respectifs pour des instructions détaillées. Une fois que tout est configuré, vous devez avoir un projet que vous souhaitez contrôler. De plus, vous avez besoin d'un endroit pour agir en tant que référentiel en amont. Peut-être avez-vous un compte Azure DevOps ? Bitbucket ? GitHub ? Plusieurs options s'offrent à vous pour héberger votre contrôle de code source. Zut, si vous êtes enclin, vous pouvez même configurer un serveur git privé. Mais cela sort également du cadre de l'article. Encore une fois, je vous renvoie à la documentation du fournisseur respectif pour configurer un référentiel vierge.

Une fois que vous avez un référentiel vierge, vous devriez recevoir un lien vers celui-ci. Nous utilisons Auzre DevOps et nous avons créé un nouveau référentiel situé à cette URL :
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
Maintenant que nous avons un lien vers un référentiel vierge, nous pouvons commencer la configuration.

Création d'un dépôt local

Bien qu'OASIS-SVN dispose d'un assistant, je trouve plus facile de cloner un référentiel existant et de travailler à partir de là. Vous êtes libre d'utiliser l'assistant qui fera quelque chose de similaire, mais je pense que suivre la méthode manuelle vous aidera à comprendre ce qui se passe réellement et facilitera le travail avec les outils. Nous supposerons que nous avons une application dans un dossier particulier :

Le dossier Source est vide et sera l'endroit où nous hébergerons les fichiers texte de notre référentiel local. Nous pouvons cliquer avec le bouton droit sur un espace blanc dans le dossier pour ouvrir le TortoiseGit menu contextuel et choisissez cloner le référentiel.

Dans la boîte de dialogue qui s'ouvre, saisissez l'URL que vous avez reçue de votre hébergeur :

ATTENTION

Vous devriez alors obtenir une boîte de dialogue indiquant que le référentiel a été cloné :

Suite au clonage, vous aurez maintenant un dossier caché nommé .git . C'est ainsi que git garde une trace de vos commits et modifications dans votre dépôt local.

Nous avons maintenant un référentiel local fonctionnel que nous pouvons ensuite utiliser pour conserver nos fichiers texte à partir d'Access. Nous devrons configurer OASIS-SVN pour en faire usage.

Configurer OASIS-SVN

Comme mentionné précédemment, OASIS-SVN dispose d'un assistant qui peut être utilisé pour nous configurer, mais nous voulons le faire manuellement afin que vous soyez familiarisé avec le fonctionnement d'OASIS-SVN et que vous puissiez ainsi utiliser l'assistant efficacement. Nous allons commencer par aller dans les Paramètres dans l'onglet du ruban OASIS-SVN.

Cela ouvrira la boîte de dialogue. Pour le moment, nous n'avons besoin de faire qu'une seule chose ; configurer le chemin source. En général, je trouve plus pratique d'utiliser un chemin relatif plutôt qu'un chemin absolu, nous allons donc mettre \Source comme illustré :

Une fois inséré, vous devez ensuite cocher la case toujours utiliser :

Cela rend le dossier du référentiel relatif et vous permet ainsi de déplacer le dossier du projet où vous le souhaitez. Mais attention - si vous copiez ou déplacez le fichier Access en dehors de ce dossier, il ne peut pas être conservé sous le contrôle du code source car OASIS-SVN n'aurait alors pas le .oasis fichier dont OASIS-SVN a besoin. Cliquez sur OK pour fermer la boîte de dialogue afin d'enregistrer les modifications apportées aux paramètres. Si vous regardez dans le dossier, vous verrez maintenant le .oasis fichier pour votre fichier ACCDB.

Le .oasis Le fichier est juste un fichier XML qui contient tous les paramètres du projet, et il doit avoir le même nom que le fichier ACCDB afin qu'OASIS-SVN sache que ce fichier ACCDB doit être sous le contrôle du code source. Ainsi, si vous avez l'habitude de renommer votre fichier ACCDB, vous devrez rompre cette habitude. Si votre flux de travail existant implique de renommer le fichier, une approche que je trouve pratique consiste à utiliser un nom fixe pour la copie de développement (par exemple, SampleApplication Dev.accdb , peut-être), puis lorsque j'ai besoin de changer le nom, je fais une copie de ce fichier et je fournis le nom correct. Il faut souligner qu'avec cela dans le contrôle du code source, renommer comme moyen de garder une trace des versions a moins de sens maintenant puisque vous devriez être en mesure de le recréer à partir de l'historique de git plutôt que d'avoir un tas de copies nommées différemment.

Configuration du reste des paramètres

À l'étape précédente, nous avons uniquement configuré le fichier source car nous n'avions pas de .oasis dossier; si nous avions apporté d'autres modifications, il n'aurait peut-être pas été enregistré, mais maintenant nous en avons créé un à la suite de la définition du dossier du projet, nous pouvons revoir le reste des paramètres. C'est probablement une bonne idée d'envisager d'avoir un modèle .oasis fichier afin que vous puissiez rapidement copier et modifier à la main pour avoir un paramètre de projet uniforme pour vos différents projets Access. Revenons aux Paramètres sur le ruban et commencez par le premier onglet de la boîte de dialogue.

Volet Types d'objets

Parce que nous ne travaillons plus avec les ADP et que nous n'utilisons pas les pages d'accès aux données obsolètes, nous décochons généralement celles-ci afin de réduire au minimum l'encombrement de la boîte de dialogue d'importation/exportation. Vous pouvez également trouver pratique de le faire sélectionner automatiquement le changement automatique, ce qui nécessite le suivi de l'horodatage de l'objet. Cependant, sachez que l'horodatage de l'objet n'est pas entièrement fiable dans Access. Nous en discuterons plus en détail dans une section ultérieure. Cela dit, c'est un bon moyen d'aider à signaler si vous avez peut-être oublié de commettre un objet errant.

Volet Options de tableau

Ce volet nécessitera quelques réflexions approfondies et dépendra du type de projets auxquels vous avez affaire. La règle numéro un est que vous ne voulez _pas_ que le code source contrôle les données de vos tables. Cela n'a pas de sens, puisque les données ne sont pas du code. Cependant, ce n'est pas toujours strictement vrai. Par exemple, nous avons un certain nombre de tables que nous utilisons comme données de configuration d'application. Ainsi, dans un sens, ces tables sont du "code" puisqu'elles influencent le fonctionnement de l'application. Parce que la majorité de nos projets sont des frontaux Access avec un backend SQL Server, les tables qui sont généralement présentes sont principalement des tables de configuration et donc appropriées pour le contrôle du code source. Mais, si nous avions des tableaux de données, ceux-ci ne devraient probablement pas être inclus. C'est là que le Avancé le bouton est pratique. Cliquez dessus pour ouvrir cette boîte de dialogue :

En décochant la case Exporter les données pour toutes les tables case à cocher en bas, vous pouvez ensuite sélectionner les données des tables que vous souhaitez conserver sous le contrôle du code source, à l'exclusion de celles qui ne sont que des tables de données et ne font pas partie du code source de l'application.

Nous n'incluons généralement pas non plus les tables liées ODBC car nous avons généralement une routine de code pour relier les tables, donc l'avoir dans le contrôle du code source n'a pas de sens pour nous. Cependant, avoir la table de configuration de l'application ou peut-être même juste la définition de la table locale est une bonne idée car nous aurions une application cassée si nous construisions un fichier à partir du référentiel git sans la définition de ces tables.

Volet Paramètres

Nous l'avons déjà vu lors de la création du .oasis dossier. Maintenant que nous avons le fichier, nous allons configurer le reste des paramètres. Voici notre configuration type.

Comme je l'ai mentionné au début, vous pourriez éventuellement écrire votre propre routine d'importation/exportation. Cependant, la valeur d'OASIS-SVN est que nous pouvons résoudre divers problèmes qui existent avec la conservation des fichiers texte Access sous le code source. Par exemple, un fichier texte Access peut avoir les champs typiques en haut de son fichier :
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form
Ceux-ci sont mauvais pour le contrôle du code source car ils peuvent introduire des changements inutiles et polluer l'historique des changements qui ne sont pas vraiment des changements. La somme de contrôle peut changer même si vous n'avez rien changé au formulaire lui-même. Avec OASIS-SVN, nous pouvons supprimer ces données inutiles à l'aide de l'option Nettoyer les fichiers exportés :
Version =21
VersionRequired =20
Begin Form
...
End Form
Vous avez peut-être remarqué une icône d'avertissement jaune pour les rapports. La raison pour laquelle il est là est que OASIS-SVN supprimera également les données de l'imprimante, ce qui est notoirement mauvais pour le contrôle du code source. Lorsque les rapports utilisent l'imprimante par défaut, ce n'est généralement pas un problème. Cependant, il n'est pas rare de créer des rapports qui dépendent d'une imprimante spécifique. Par exemple, nous avons peut-être un rapport qui crée une étiquette de code-barres sur une imprimante spécialisée. Dans ce rapport, nous aurons choisi une imprimante spécifique plutôt qu'une imprimante par défaut. Cocher cette case pour les rapports signifie que les données de l'imprimante seront époustouflées. Si votre projet ne dépend d'aucune configuration d'imprimante particulière, vous trouverez peut-être plus facile de cocher les rapports. Sinon, il n'y a aucune raison de ne pas le cocher pour les formulaires.

Pour des raisons similaires, nous aimons vraiment avoir des fichiers Split Form et Fichiers de rapports fractionnés option cochée. Normalement, Application.SaveAsText exportera un seul fichier texte pour un seul objet Access. Cependant, si vous avez lu le fichier texte, vous verrez que le code de mise en page peut être... fastidieux à lire. Cocher cette option signifie que nous obtenons 2 fichiers texte par objet Access; l'un pour contenir toutes les données de mise en page, et l'autre le code source VBA réel derrière le formulaire. Cela rend la révision du code beaucoup plus facile puisque vous pouvez vous concentrer sur les modifications VBA et comprendre ce qui a changé, ce qui facilite la compréhension de la modification de la mise en page.

Vous vous souviendrez peut-être que de la section précédente sur les types d'objets volet, nous avons choisi le modifié, ce qui nous oblige à enregistrer la date/heure de l'objet en tant que date/heure de fichier. C'est coché ici aussi. Il convient de noter qu'Access n'estampille pas toujours de manière fiable l'horodatage lors de la modification des objets. Nous en reparlerons dans une section ultérieure sur les commits.

Volet d'intégration

Nous voulons généralement nous assurer que la correction automatique est toujours désactivée, mais le plus important est l'option d'utiliser Ctrl+S comme raccourci pour effectuer une exportation. C'est très très utile et évite le problème avec l'horodatage de l'objet Access. Cependant, cela nécessite de la discipline pour utiliser systématiquement le raccourci clavier pour enregistrer les modifications. Chaque fois que vous exécutez le clavier, vous verrez brièvement cette boîte de dialogue :

Cela garantit que votre arbre de travail git est maintenu en synchronisation avec votre fichier ACCDB de travail pendant que vous travaillez sur les modifications. Il est important de souligner que vous n'avez pas à hésiter à sauvegarder fréquemment - cela ne signifie pas nécessairement que vous devez valider chaque sauvegarde, mais en sauvegardant fréquemment, votre arbre de travail reflétera avec précision l'étendue de vos modifications lorsque vous sont prêts à s'engager. Nous en discuterons en détail dans une section ultérieure.

MISE À JOUR automatique avant importation et COMMIT automatique après l'exportation peut sembler une chose pratique mais en pratique, nous avons trouvé qu'il était bien préférable de le faire manuellement, surtout lorsque nous exportons avec le raccourci Ctrl+S puisque nous ne voulons pas nécessairement valider ; enregistrez uniquement notre travail en cours afin que nous sachions ce qui a changé lorsque nous sommes réellement prêts à nous engager. Pour cette raison, nous les laissons de côté.

.oasis Fichier de configuration

Une fois que vous avez cliqué sur OK dans la boîte de dialogue des paramètres, les modifications que vous avez apportées dans divers volets seront ensuite écrites dans le .oasis fichier sous forme XML. Comme mentionné, vous pouvez le copier et créer un modèle afin de disposer d'un moyen rapide de configurer une autre application Access. Nous sommes maintenant prêts à effectuer un contrôle réel du code source.

Exportation et validation

Comme déjà mentionné, parce que nous travaillons avec un fichier binaire, nous devons tout exporter dans une représentation textuelle afin qu'ils puissent être correctement gérés par le contrôle du code source. Pour ce faire, nous devons exporter les objets. Vous pouvez utiliser le bouton d'exportation OASIS-SVN comme indiqué.

Vous obtiendrez une boîte de dialogue avec tous les types d'objets répertoriés pour l'exportation. Comme il s'agit de notre première exportation, nous utiliserons Ctrl + A pour tout sélectionner à exporter.

Cliquez sur OK pour terminer l'exportation. Si tout se passe bien, vous recevrez un message l'indiquant.

Si vous regardez à l'intérieur du dossier source, vous verrez tous les fichiers texte représentant divers objets que vous venez d'exporter. Notez que la convention de dénomination peut être différente selon ce que vous avez sélectionné dans le volet Paramètres, comme indiqué dans la section précédente. De plus, parce que nous avons choisi de diviser les fichiers, nous avons à la fois un .def et un .layout fichier pour un seul objet Access.

Avec les objets exportés sous forme de fichiers texte, nous devons maintenant valider nos modifications. OASIS-SVN fournit les commandes TortoiseGit directement depuis Access, comme indiqué.

En règle générale, les 4 commandes que vous souhaitez utiliser sont affichées ici - les autres commandes sont bonnes à utiliser, mais nous n'avons pas à nous en soucier jusqu'à ce que nous arrivions à des scénarios git plus complexes. Au fait, ces commandes sont en fait les mêmes commandes qui sont exposées par TortoiseGit via le menu contextuel de l'explorateur Windows :

De plus, un sous-ensemble de commandes est disponible via le menu contextuel du volet de navigation Access :

Ainsi, vous avez plusieurs façons de travailler avec OASIS-SVN ou avec TortoiseGit directement depuis Access, ou vous pouvez simplement utiliser TortotiseGit directement depuis l'explorateur Windows. Notez que vous avez Commit dans toutes les captures d'écran ; qui sera notre prochaine étape. Le choisir ouvrira une boîte de dialogue TortoiseGit :

Vous souhaiterez généralement tout sélectionner. Notez qu'il ne suit que les fichiers texte que nous avons mis dans le dossier du projet. Ce point mérite d'être souligné; si vous n'avez pas exporté un objet depuis Access, git ne peut pas le savoir. Vous devez fournir un message de validation descriptif ; plus c'est détaillé, mieux c'est. Nous préférons également faire plusieurs petits commits car ainsi l'historique est plus facile à comprendre. Vous ne voulez pas faire un commit une fois par semaine avec 1000 changements; ce serait impossible à comprendre. Vous souhaitez un commit après avoir terminé une tâche (par exemple, la correction d'un bogue spécifique ou l'introduction d'une fonctionnalité), afin que votre historique soit facile à comprendre.

Au fur et à mesure que vous prenez l'habitude de commiter votre travail, vous voudrez peut-être noter que TortoiseGit vous offre 3 options pour commiter :

Recommit est utile si vous devez effectuer plusieurs commits parce que vous avez effectué 2 tâches ou plus et que vous souhaitez séparer le commit pour chaque tâche. Il est probablement préférable de ne pas avoir à le faire et de valider dès que vous avez terminé une tâche, mais si vous êtes pris dans l'excitation, vous cochez simplement un sous-ensemble de fichiers que vous souhaitez valider et cliquez sur Revalider. TortoiseGit validera uniquement ces sous-ensembles de fichiers, puis réinitialisera la boîte de dialogue de validation afin que vous puissiez valider les autres sous-ensembles de fichiers avec un message séparé.

Valider et pousser est souvent utilisé pour combiner commit et push. Il est important de se rappeler que les commits n'écrivent que dans votre référentiel git local. Mais nous avons commencé avec un référentiel distant. Vous ne pouvez pas partager vos modifications de code avec vos collègues ou avoir une sauvegarde à distance de votre travail tant que vous n'avez pas poussé vos commits locaux sur le serveur, et c'est à cela que sert le push. Nous en discuterons en détail plus tard.

Lorsque vous validez, TortoiseGit vous fournira une boîte de dialogue de progression et vous avertira si cela a réussi.

Conclusion

Jusqu'à présent, vous avez appris à configurer un référentiel git, à configurer OASIS et à effectuer votre premier commit. Cependant, cela ne fait qu'effleurer la surface. La pleine puissance de git n'est pas encore apparente tant que vous ne vous lancez pas dans la création de branches, la lecture de l'historique et la résolution des conflits. Cependant, ce sont strictement des choses git et ont moins à voir avec Access ou OASIS; tout guide git général que nous avons déjà lié au début de l'article sera très utile pour comprendre comment gérer un référentiel git. Il vaut la peine de rappeler que TortoiseGit n'est qu'un mince wrapper GUI sur les commandes git, donc même si le tutoriel parle d'utiliser un shell bash, vous devriez pouvoir faire la même chose via le menu TortoiseGit portant le même nom. Avoir des questions? Demandez dans les commentaires !