Git Rebase et refactorisation de code pour l'outil VShell

Cette semaine, j'ai eu l'occasion de me plonger dans l'utilisation de git rebase tout en refactorisant la base de code de mon outil VShell. Ma tâche principale consistait à améliorer la structure et la maintenabilité du code tout en adhérant au principe DRY (Don't Repeat Yourself), essentiel pour rendre le code plus lisible, maintenable et plus facile à déboguer. De plus, j'ai suivi divers modèles de refactoring décrits dans le catalogue de refactoring, tels que l'extraction de fonctions, l'extraction de classes et le renommage de variables.

Avant de plonger dans les détails de mes efforts de refactoring, je vais donner un aperçu du processus de rebase de Git aux développeurs qui se familiarisent encore avec cette puissante fonctionnalité de Git.

Présentation du rebase Git

Commandes de base :

• git rebase  : Cette commande déplace les commits de la branche actuelle au-dessus de la branche spécifiée, rebasant ainsi la branche actuelle.

• git rebase  : cette commande rebase la branche thématique sur la branche de base sans avoir besoin d'extraire au préalable la branche thématique.
  Exemple : Normalement, vous consulteriez la branche topic et exécuteriez git rebase, mais cette commande permet de rebaser tout en restant dans la branche de base.

Gestion des conflits :

• git rebase --abort : annule le rebase et restaure la branche à son état précédent.
• git add  : ajoute les conflits résolus à la zone de préparation après avoir résolu les conflits de fusion.
• git rebase --continue : continue le processus de rebase une fois les conflits résolus.

Rebase interactif :

• Utilisez git rebase -i pour écraser plusieurs commits en un seul.
• Après un rebase réussi, les branches du sujet peuvent être supprimées, car toutes les modifications sont intégrées. Utilisez git branch -d pour supprimer la branche.

Remarques importantes : :

• Évitez de rebaser la branche principale, car cela affecte d'autres collaborateurs.
• Rebasez uniquement sur votre branche thématique pour nettoyer votre travail avant de pousser.

→ rebasez les modifications locales avant de les pousser pour nettoyer votre travail, mais ne rebasez jamais rien de ce que vous avez poussé quelque part.

Processus de refactorisation

1. Création d'une branche de refactoring
   Pour éviter de casser le code de travail actuel, j'ai créé une branche de refactorisation distincte basée sur la branche principale. Cela m'a permis d'expérimenter les changements en toute sécurité.

2. Analyser et refactoriser le code
   Bien que j'aie initialement appliqué un modèle modulaire au code VShell, des améliorations supplémentaires étaient nécessaires pour diviser des modules plus grands et créer un flux de code plus lisible.

   • src/serveur :
     • J'ai refactorisé la logique de journalisation répétée dans une fonction handleDebugMessage(), permettant une journalisation centralisée via le flux stderr.
     • J'ai également créé une nouvelle classe ConfigHandler dans ConfigHandler.js pour gérer le traitement du fichier de configuration .toml. Les méthodes getTomlFiles() et loadConfig() ont été encapsulées dans cette classe pour une gestion modulaire des paramètres.

• ai_config/grogConfig.js :

  • Deux façons de renvoyer les réponses de l'IA chatCompletion présentaient une duplication dans la récupération de l'utilisation des jetons. J'ai extrait cette logique dans une fonction getTokenUsage(), permettant à readStream() et promptGroq() de la réutiliser.
  • De plus, j'ai corrigé la faute de frappe dans promptGroq() et renommé la variable de température pour une meilleure clarté.

• src/ai.js :

  • J'ai déplacé la fonction handleOutput() dans un module handleOutputFile() pour permettre une réutilisation future.

• src/getFileContent.js :

  • Des changements minimes étaient nécessaires ici ; J'ai simplement renommé les chemins de fichiers et les noms de variables pour une meilleure lisibilité et clarté.

Git Rebase après la refactorisation

Après avoir effectué 11 commits lors du processus de refactoring, il est devenu nécessaire de les consolider. Pour garder l'historique des commits propre, j'ai effectué un rebase interactif en utilisant :

git rebase main -i

VSCode, configuré comme mon éditeur Git, m'a invité à écraser les commits. Après l'écrasement, j'ai eu un seul commit avec tous les changements pertinents. J'ai ensuite utilisé git commit --amend pour mettre à jour le message de validation au lieu de créer un nouveau commit avant de le fusionner dans la branche principale.

결론

이번 주의 git rebase 경험은 나에게 귀중한 통찰력을 제공했습니다. Rebase는 불필요한 병합 없이 깨끗하고 선형적인 커밋 기록을 유지하기 위한 필수 도구입니다. git rebase를 마스터함으로써 이제 커밋 메시지를 효율적으로 구성하고 혼란을 최소화하며 간소화된 개발 워크플로를 보장할 수 있습니다.

리팩토링 노력으로 VShell 코드베이스의 구조와 유지 관리성이 향상되었습니다. 함수 및 클래스 추출과 같은 주요 디자인 패턴을 적용하여 코드베이스를 더욱 모듈화하고 재사용 가능하며 앞으로 작업하기 쉽게 만들었습니다.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!