Git Lane

Extension VS Code pour résoudre des conflits Git dans un panneau à trois volets, et pour lire l’état du dépôt sans le confondre avec l’interface Git déjà fournie.

Version actuelle : 0.2.24. Le journal Git s’ouvre en bas de la fenêtre : arbre des branches, graphe des commits, fichiers du commit choisi. Le clic droit sur un fichier ou un dossier de l’explorateur ouvre le menu Git. Sur un fichier modifié, ces actions s’affichent directement. L’icône de branche est sur la barre d’actions de l’explorateur, avec Nouveau fichier. L’anglais est la langue par défaut ; le français est utilisé quand la langue d’affichage de VS Code commence par fr. Le staging par ligne n’est pas implémenté.

Prérequis

• Visual Studio Code 1.96 ou plus récent (développé avec les types 1.96.0, vérifié sur VS Code 1.140).
• Git 2.x disponible dans le PATH, ou un chemin explicite.
• Un dossier de workspace approuvé (Workspace Trust) pour enregistrer une résolution ou indexer un fichier.

La première ouverture d’une vue lance des lectures (rev-parse, status, ls-files, et log pour l’historique). Le menu de branche lit la branche courante à l’ouverture.

Installation locale

npm ci
npm run package
code --install-extension git-lane-0.2.24.vsix

Pour développer : ouvrir ce dossier, lancer la tâche de compilation, puis « Lancer Git Lane ».

Ce qui fonctionne

• Découverte du dépôt ouvert, y compris un worktree. Un dépôt parent situé hors du dossier ouvert est ignoré.
• Exécution de Git par spawn, sans shell, avec délai, annulation, plafond de sortie et journal expurgé.
• Liste des changements : index, arbre de travail et fichiers non suivis. Les conflits sont uniquement dans la vue Conflits.
• Clic droit dans l’arbre de travail : désindexer, mettre de côté (confirmation), supprimer le fichier (confirmation), afficher le diff, l’ouvrir dans un nouvel onglet, comparer HEAD / index / arbre, aller au fichier, créer ou copier un patch, afficher l’historique Git et l’historique local de l’éditeur.
• Journal Git en bas de la fenêtre, sur toute la largeur : à gauche HEAD, Local, Distant et Étiquettes ; au centre le graphe, la description, l’utilisateur et la date ; à droite les fichiers du commit et son résumé. Choisir une branche filtre le journal. Un fichier ouvre le diff. La commande « Historique du dépôt » affiche ce journal.
• Panneau « Historique » : Récent, Local, Distant et Étiquettes, puis les commits. Un dossier regroupe les noms qui contiennent une barre (jd/10 dans jd). La branche courante a une étoile et le suivi (origin/main) en description. Le chevron s’affiche au survol. Il ouvre le sous-menu : extraire, nouvelle branche depuis cette branche, extraire et rebaser sur la branche courante, comparer, diff avec l’arbre de travail, rebaser la branche courante, fusionner dans la branche courante, mettre à jour, pousser, renommer, supprimer. Le clic droit reprend ces actions. La suppression locale utilise git branch -d et échoue si la branche n’est pas fusionnée. Un clic sur un commit ouvre le journal dans l’éditeur.
• Clic droit sur un fichier de l’explorateur, de l’éditeur, des changements Git natifs, de l’index, des non suivis ou des conflits : le même menu que l’arbre de travail (désindexer, mettre de côté, supprimer, diff, comparaison, patch, historique).
• Icône de branche sur la barre d’actions de l’explorateur, à gauche de Nouveau fichier. Cette barre est sur le titre « Explorer » quand les fichiers sont la seule section. Avec Plan ou Chronologie, elle reste en haut de la liste des fichiers, toujours visible. Le menu cherche une branche ou une action : mettre à jour le projet (fusion ou rebase), créer un commit, pousser, créer une branche, extraire une étiquette ou un hash, ou extraire une branche listée.
• Outil de fusion :
  • à gauche, la version locale ;
  • au centre, le résultat modifiable ;
  • à droite, la version entrante ;
  • bloc par bloc : accepter la locale, accepter l’entrante, combiner ;
  • actions globales séparées : tout accepter, conserver les régions déjà fusionnées, enregistrer, marquer comme résolu ;
  • navigation précédent / suivant et raccourcis documentés ci-dessous.
• Merges, rebases et cherry-picks. Pendant un rebase, « locale » désigne le commit rejoué.
• Conflits binaires, suppression/modification et renommage/renommage classique : le choix porte sur le fichier entier et une suppression demande une confirmation.
• Avant d’indexer : fichier enregistré, plus de marqueur, dépôt inchangé depuis l’ouverture, aucun autre chemin ajouté à l’index.

La commande « Ouvrir l’éditeur de fusion natif » délègue à git.openMergeEditor, fournie par l’extension Git intégrée. Elle ne pilote pas les blocs. La commande privée _open.mergeEditor n’est pas appelée : VS Code n’expose pas d’API publique pour cela (demande microsoft/vscode#252521, toujours ouverte lors de la vérification du 24 octobre 2026).

Raccourcis

Quand le panneau de fusion est actif :

Ces raccourcis sont aussi définis dans les contributions de l’extension et peuvent être modifiés dans le clavier de VS Code.

Configuration

Limites de cette version

• Le graphe d’historique est une colonne de voies, pas le graphe complet d’un client JetBrains. Pas de staging par ligne : un commit valide l’index, les fichiers suivis modifiés, ou tous les fichiers non ignorés, selon le choix explicite.
• Mettre à jour le projet fait git pull (fusion --no-rebase ou rebase), après confirmation. Pousser fait git push, ou git push -u <distant> HEAD s’il n’y a pas encore de suivi. Aucun force-push. Créer une branche fait git switch -c. Extraire une étiquette ou un hash fait git switch --detach, après confirmation. Changer de branche fait git switch.
• Le sous-menu d’une branche peut rebaser la branche courante (git rebase), la fusionner (git merge --no-edit) ou extraire une branche puis la rebaser, après confirmation. Mettre à jour une branche non extraite fait un git fetch en avance rapide seulement. Pas de cherry-pick. Pas de stash global. Un rebase, cherry-pick, revert ou merge en cours bloque le changement de branche, la mise à jour et le push.
• git reset --hard, git clean et git checkout -- ne sont pas utilisés. Désindexer un fichier passe par git restore --staged. Mettre de côté un fichier passe par git stash push -- <fichier>, après confirmation. Supprimer retire le fichier du disque, après confirmation, sans git rm.
• Le renommage géré automatiquement est le cas « un ancêtre, un chemin de chaque côté ». Les autres formes sont affichées et laissées intactes.
• La fusion par bloc suppose un fichier UTF-8 sans octet nul. Un fichier binaire ou non UTF-8 se résout en entier.
• Les marqueurs imbriqués ou orphelins bloquent la résolution par bloc.
• Enregistrer écrit le fichier du conflit. Marquer comme résolu n’indexe que les chemins de ce conflit.
• Une modification du dépôt pendant la session (autre résolution, commit, édition du fichier) interrompt l’écriture. Il faut rouvrir l’outil.
• Les captures d’écran ne sont pas encore incluses.
• Publication Marketplace non faite. L’éditeur est git-lane. Aucun jeton n’est demandé ni stocké.

Vérification

npm ci
npm run compile
npm run lint
npm run test:unit
npm run test:integration
npx @vscode/vsce package --no-dependencies --allow-missing-repository

npm run package enchaîne compilation, lint, tests et contrôle des licences. Il n’y a pas de dépendance d’exécution. Les outils de développement utilisent des licences MIT, ISC, BSD ou Apache-2.0.

Les tests d’intégration créent des dépôts temporaires et fixent user.name / user.email localement. Ils ne lisent pas l’identité Git de la machine.

Les tests dans l’hôte d’extension VS Code (@vscode/test-cli) ne sont pas branchés dans cette tranche : la logique de fusion est couverte sur de vrais dépôts, et l’interface est une Webview dont le contrat de messages est testé sans lancer VS Code.

Publication

La publication exige un compte éditeur et un jeton fourni au moment de la commande, jamais dans le dépôt :

npx @vscode/vsce login <editeur>
npx @vscode/vsce publish

Ne pas publier cette version sans revue explicite.