Lorsque vous renommez des fichiers dans un projet (php, nodejs ou autre…), Git peut parfois ne pas détecter les changements de nom, surtout si la casse des lettres a été modifiée.
Voici comment vous pouvez vous assurer que les fichiers renommés sont pris en compte par Git :
1. Utiliser la commande `git mv` :
Utilisez la commande `git mv` pour renommer les fichiers. Cela permet à Git de suivre correctement les changements de nom.
```bash
git mv ancien_nom.php nouveau_nom.php
```
2. Vérifier les changements :
Après avoir renommé les fichiers, vérifiez les changements avec la commande `git status` pour vous assurer que Git a bien pris en compte les modifications.
```bash
git status
```
3. Ajouter les changements :
Ajoutez les fichiers renommés à l’index de Git.
```bash
git add .
```
4. Valider les changements :
Validez les changements avec un message de commit approprié.
```bash
git commit -m "Renommé les fichiers pour respecter les conventions de nommage"
```
5. Configurer Git pour ignorer la casse (si nécessaire):
Si vous avez des problèmes avec la casse des lettres, vous pouvez configurer Git pour qu’il soit sensible à la casse.
```bash
git config core.ignorecase false
```
En suivant ces étapes, vous devriez pouvoir renommer vos fichiers et les faire reconnaître correctement par Git.
Tu as fait des modifications dans un commits et tu as changé de branche sans poussé ? Pour revenir à l’état du HEAD détaché basé sur le commit nommé, par exemple, 5a66bba où tu as fait des commits sans les pousser, tu peux suivre ces étapes :
Localiser le commit exact où tu étais : Lorsque tu étais dans un état de HEAD détaché, Git n’associe pas tes commits à une branche spécifique. Cependant, ces commits ne sont pas perdus. Tu peux les retrouver dans l’historique de Git. Utilise la commande suivante pour afficher les derniers commits effectués dans le dépôt, y compris ceux non référencés par une branche :
git reflog
Le reflog enregistre toutes les actions que tu as faites dans ton dépôt local, y compris les HEAD détachés. Cherche l’entrée où le commit 5a66bba est mentionné ou celle qui correspond à tes commits récents.
Revenir au commit spécifique : Une fois que tu as identifié le commit exact où tu étais, utilise la commande suivante pour revenir à cet état de HEAD détaché :
git checkout <hash-du-commit>
Remplace <hash-du-commit> par l’identifiant du commit que tu veux restaurer (celui où tu as fait des commits supplémentaires).
Créer une branche pour éviter de perdre tes changements : Puisque tu étais dans un état de HEAD détaché, il est préférable de créer une nouvelle branche pour sécuriser tes commits. Utilise la commande suivante :
git checkout -b nouvelle-branche
Cela te permettra de continuer à travailler sur tes commits et de les pousser si nécessaire.
Résumé des commandes :
git reflog : Pour trouver le commit où tu étais.
git checkout <hash> : Pour revenir à cet état de HEAD détaché.
git checkout -b nouvelle-branche : Pour créer une branche et sécuriser tes commits.
Cela te permettra de retrouver ton travail sans rien perdre.
J’ai beau connaître composer depuis quelques années, j’en apprend encore aujourd’hui.
Composer, l’outil de gestion de dépendances PHP, a introduit une fonctionnalité essentielle pour la sécurité : l’audit des packages. Dans cet article, nous explorerons en détail ce qu’est l’audit des packages, comment l’utiliser et pourquoi il est crucial pour la sécurité de vos projets.
Qu’est-ce que l’audit des packages ?
L’audit des packages est un processus qui permet de détecter les vulnérabilités de sécurité dans les dépendances de votre projet. Lorsque vous utilisez des packages tiers (comme des bibliothèques ou des frameworks), il est essentiel de s’assurer qu’ils ne contiennent pas de failles de sécurité connues. C’est là que l’audit des packages entre en jeu.
Comment fonctionne l’audit des packages avec Composer ?
Vérification automatique lors de l’installation et de la mise à jour :
Depuis Composer 2.4, chaque fois que vous installez ou mettez à jour un package, Composer vérifie automatiquement les versions installées et les nouvelles versions à la recherche de vulnérabilités connues.
Si une version vulnérable est détectée, Composer affiche un avertissement.
Commande composer audit :
La commande composer audit vous permet de lister les vulnérabilités de sécurité signalées pour les versions actuellement installées des packages.
Elle affiche les informations suivantes :
Nom du package
Identifiant CVE
Titre de l’avis de sécurité
Lien vers l’avis de sécurité
Plage(s) de versions affectées
Date de publication de l’avis
Formats de sortie personnalisables :
Vous pouvez spécifier le format de sortie pour les vulnérabilités détectées en utilisant l’option --audit-format.
Formats pris en charge : table, plain, json et summary.
Utilisation en CI/CD :
Les pipelines CI/CD peuvent exécuter composer audit pour s’assurer qu’il n’y a pas de vulnérabilités connues avant de déployer l’application.
Exemple d’utilisation
Supposons que vous souhaitiez installer une version vulnérable de Guzzle (par exemple, la version 7.4.4). Voici comment Composer réagit :
Composer installe le package, mais affiche un avertissement concernant la vulnérabilité détectée.
Conclusion
L’audit des packages avec Composer est un outil puissant pour renforcer la sécurité de vos projets PHP. Utilisez-le régulièrement pour vous assurer que vos dépendances sont à l’abri des vulnérabilités connues. Voici quelques conseils pour une utilisation efficace :
Mettez à jour vos packages : Lorsqu’une vulnérabilité est corrigée dans une nouvelle version d’un package, assurez-vous de mettre à jour votre projet pour bénéficier de la correction.
Surveillez les alertes de sécurité : Abonnez-vous aux notifications de sécurité pour les packages que vous utilisez. Ainsi, vous serez informé rapidement des nouvelles vulnérabilités.
Vérifiez les dépendances de vos dépendances : Les packages que vous installez peuvent eux-mêmes avoir des dépendances. Assurez-vous que ces dépendances sont également sécurisées.
Utilisez des outils complémentaires : En plus de Composer, explorez d’autres outils d’analyse statique et dynamique pour renforcer la sécurité de votre code.
En appliquant ces bonnes pratiques, vous contribuerez à protéger vos applications PHP contre les menaces potentielles. N’oubliez pas que la sécurité est l’affaire de tous, et chaque petit geste compte !
L’amélioration et la maintenance du code PHP sont des aspects cruciaux du développement logiciel, visant à garantir la fiabilité, la performance et la pérennité des applications. Pour ce faire, l’utilisation de bibliothèques bien choisies joue un rôle essentiel. Ces librairies offrent des fonctionnalités prêtes à l’emploi, facilitant le développement, la gestion des dépendances, et assurant une base solide pour des mises à jour et des corrections efficaces. Opter pour des bonnes pratiques de codage, comme la modularité et la documentation claire, contribue également à simplifier la maintenance du code PHP sur le long terme.
Il existe librairies en PHP, qui aident à la maintenabilité du code en PHP en donnant les infos à améliorer. Ces librairies sont les suivantes : phploc, phpcs, phpmd, phpdd
phploc, ou comment décortiquer la complexité du code PHP
PHPLOC est un outil d’analyse statique pour les projets PHP, permettant de mesurer diverses métriques de code. Il fournit des informations détaillées sur la taille et la complexité d’un code source PHP, en comptant notamment le nombre de classes, de méthodes, de traits, de lignes de code, et d’autres indicateurs pertinents. Cet outil est souvent utilisé dans le processus d’évaluation de la qualité du code et peut aider les développeurs à comprendre la structure et la complexité de leur projet. En résumé, PHPLOC offre une vision quantitative des caractéristiques du code source PHP.
$ php phploc.phar src
phploc 8.0-dev by Sebastian Bergmann.
Directories: 104
Files: 856
Lines of Code (LOC): 67,955
Comment Lines of Code (CLOC): 19,533 (28.74%)
Non-Comment Lines of Code (NCLOC): 48,422 (71.26%)
Logical Lines of Code (LLOC): 18,478 (27.19%)
Classes or Traits 662
Methods 3,389
Cyclomatic Complexity
Lowest 1.00
Average 2.00
Highest 156.00
Functions 185
Cyclomatic Complexity
Lowest 1.00
Average 1.00
Highest 1.00
PHPCS, ou PHP CodeSniffer, est un outil d’analyse statique de code pour PHP. Il permet de détecter et de signaler les violations des normes de codage définies, telles que PSR-1, PSR-2, et des conventions personnalisées. PHPCS facilite ainsi le maintien de la cohérence et de la lisibilité du code au sein d’un projet PHP, en offrant des recommandations et des corrections automatisées pour s’assurer que le code respecte les standards établis. Cet outil est largement utilisé dans le processus de développement pour garantir une qualité uniforme du code. En résumé, PHPCS contribue à la conformité aux normes de codage et à l’amélioration de la qualité du code PHP.
Détection automatisée des mauvaises pratiques avec phpmd
PHPMD, ou PHP Mess Detector, est un outil d’analyse statique de code conçu pour détecter les codes sources PHP potentiellement problématiques. Il se concentre principalement sur les aspects liés à la complexité du code, aux mauvaises pratiques de programmation, et à la détection des codes redondants. PHPMD propose des règles configurables pour identifier ces problèmes, offrant ainsi aux développeurs des suggestions pour améliorer la lisibilité, la maintenabilité et la performance de leur code. En somme, PHPMD est un outil précieux pour identifier et corriger des aspects critiques de la qualité du code PHP.
PhpDeprecationDetector est un outil spécifique pour la détection des dépréciations dans le code source PHP. Il est conçu pour identifier les portions du code qui utilisent des fonctionnalités ou des méthodes PHP obsolètes, signalant ainsi les points où des mises à jour sont nécessaires pour maintenir la compatibilité avec les versions PHP les plus récentes. Cet outil aide les développeurs à anticiper les changements à venir dans les futures versions de PHP et à prendre des mesures proactives pour mettre à jour leur code en conséquence. En bref, PhpDeprecationDetector contribue à assurer la pérennité des applications PHP en signalant les éléments de code sujets à des modifications dans les versions futures de PHP.
Conclusion
En conclusion, l’utilisation synergique de ces librairies représente une approche holistique pour garantir la qualité, la lisibilité et la pérennité du code PHP. En intégrant ces outils dans le processus de développement, les développeurs peuvent non seulement identifier et corriger les problèmes existants, mais aussi anticiper les évolutions futures du langage, assurant ainsi une base solide et adaptative pour leurs applications. En adoptant cette approche complète, les équipes de développement sont mieux équipées pour créer des solutions logicielles robustes, évolutives et conformes aux normes de l’industrie.
Ils existent bien d’autres librairies de ce style, et je ne manquerai pas d’en discuter, dans le futur.
Cet article est le premier, j’espère, d’une longue série qui traitera des mauvaises pratiques de développement logiciel. Les exemples que je donnerai sont issue de mes expériences professionnelles, sur des projets auxquels j’ai participé.
J’ai eu l’idée de cette série en lisant l’article Les pire bout de code du site jesuisundev.com. J’aimerai donner quelques exemples de mon expérience en tant que développeur Web.
