Faites de petits engagements-js tutoriel-php.cn

En ce qui concerne le contrôle de version, je préconise de faire de nombreux petits commits ciblés plutôt que de grands commits.

Et pendant que je suis en vie, j'apporterai de petits changements à la Terre.
— Lapin effrayé

Meilleures pratiques : de petits changements s'additionnent

L'objectif n'est pas seulement de faire des engagements petits, mais de les rendre concentrés et utiles. Chaque validation doit représenter un changement logique dans la base de code.

En fin de compte, nous pouvons arriver aux mêmes changements, mais de petits engagements nous aident à gérer notre temps et à garantir que nos tâches sont correctement accomplies, tout en laissant des informations utiles pour l'avenir.

Divisez les grands projets en tâches plus petites. Il s’agit d’une compétence traditionnelle en gestion de projet qui est essentielle pour faire bon usage de votre temps et produire des résultats positifs. La loi de Parkinson suggère que les tâches s'étendent pour occuper le temps qui leur est imparti. Ainsi, être capable d'identifier des tâches plus nombreuses et plus petites permet de limiter la perte de temps.
Pensez à la façon dont une tâche se traduit par un message de validation descriptif. Si les tâches ou les messages se chevauchent ou sont similaires, pouvez-vous fusionner ces tâches ? Sinon, identifiez les principales différences pour les distinguer. Conseil de pro : Si le mot « et » apparaît dans votre message de commit ou s'il faut plusieurs phrases pour l'expliquer, votre commit doit être divisé.
Assurez-vous que votre commit laisse le projet dans un état fonctionnel. Bien que ce ne soit pas toujours possible, cette directive est vraiment utile lorsque plusieurs développeurs travaillent sur un seul dépôt. Lorsque nous laissons le projet fonctionner, nous pouvons créer et fusionner des branches plus souvent et limiter les conflits. Et si vous devez annuler les modifications, vous êtes plus susceptible de laisser l'application fonctionnelle.
Révisez vos propres modifications avant de vous engager pour garantir votre concentration. Parfois, nous constatons des changements opportunistes ou perdons de vue la tâche principale. Même si nous ne voulons pas perdre ces informations et mises à jour, il existe plusieurs façons d'isoler les modifications dans les outils de contrôle de version et les IDE afin de conserver la distinction entre les commits.

Cohérence

À mesure que le nombre de commits augmente, il peut être difficile de garder vos commits significatifs. Pensez à adopter un style tel que les commits conventionnels pour plus de clarté et de cohérence.

Avantages

Les avantages des petits engagements deviennent évidents dans plusieurs domaines clés :

Révision du code plus facile

Les petits commits ciblés sont plus faciles à comprendre et à valider. Les réviseurs peuvent examiner différents commits de manière isolée et se concentrer sur les détails pertinents pour chaque plus petite unité de travail.

Des engagements plus petits créent moins de risque de fatigue des évaluateurs et produisent une qualité globale supérieure.

Demandez à un programmeur de revoir 10 lignes de code, il trouvera 10 problèmes. Demandez-lui de faire 500 lignes et il vous dira que ça a l'air bien.
– Giray Özil

Meilleur débogage

Les petits commits permettent d'identifier plus facilement où les problèmes ont été introduits. Avec les commits granulaires, vous pouvez utiliser plus efficacement des outils comme git bisect pour identifier les problèmes. Une fois qu'un défaut est identifié, de petits commits nous aident à limiter le risque et la portée des tests liés à la modification du code existant.

Histoire plus propre

Chaque commit doit raconter une histoire sur un seul changement. Lorsque les commits sont petits, cette histoire devient plus claire et plus significative pour les futurs développeurs, y compris vous-même.

À mesure que l'âge du projet augmente, l'historique des commits peut nous renseigner sur les chemins empruntés et abandonnés, sur les erreurs résolues et les risques dont il faut être conscient. Plus les messages de commit sont précis et précis, plus il est facile de comprendre l'historique du projet.

Fusions plus sûres

Lorsque les commits sont petits, non seulement le risque de conflits de fusion dus à des modifications qui se chevauchent diminue, mais il est également plus facile de résoudre les conflits avec des modifications plus petites.

Des restaurations plus sûres

Comme mentionné précédemment, si quelque chose ne va pas, annuler de petits commits est moins risqué que d'essayer d'annuler de gros morceaux de modifications interconnectées.

Risque moindre

Un code non validé, c'est comme avoir un document non enregistré. Plus le temps s'écoule entre la modification d'une ligne de code et son enregistrement, plus il y a de risques de perdre cette modification. Suppression accidentelle ; écrasement ; ne pas conserver une modification avant de changer de branche ; réinitialiser une branche au lieu d'un fichier... il existe de nombreuses façons de perdre du travail.

Je suis un contrôle de version moderne comme Git, le branchement est pratiquement gratuit. Bien que git stash puisse être utile à la rigueur, il nécessite presque le même effort pour créer une branche temporaire qui peut être fusionnée dans une branche de fonctionnalité ou de maintenance si elle s'avère utile.

Les modifications validées peuvent être poussées vers une branche ou un fork d'un dépôt sur un serveur, permettant à d'autres de les visualiser et de travailler dessus en collaboration et de garantir que votre système de paramètres régionaux n'est pas un point de défaillance unique qui peut vous coûter ce travail.

Faut-il écraser ?

Lors de la création de nombreux petits commits dans une branche de fonctionnalités, il peut être souhaitable de les regrouper en un seul commit à la fin, idéalement en utilisant la pull request afin de ne pas perdre l'historique discret qui est si utile lors de la révision du code.

Je préfère conserver l'historique, mais cela dépend aussi de l'ampleur et de la fréquence de ces fusions.

Des thèmes, pas des choses

Nous n'avons souvent pas besoin que chaque petit changement soit représenté à la fin, mais si les commits ne partagent pas un leitmotiv – un thème unique et global – alors ils ne devraient probablement pas être écrasés. ensemble.

Make Small Commits

Cela est lié à l'avantage Cleaner History. Pendant que le travail est en cours, ces messages distincts peuvent faciliter la détection des erreurs ou des incohérences dans la révision du code :

refactor: JIRA-12345 - Replace guards with optional chaining
refactor: JIRA-12354 - Replace logical OR with nullish coalescing

Copier après la connexion

Une fois le travail validé et prêt à fusionner, un seul commit écrasé peut les représenter :

refactor: JIRA-12345 - ES2020 update

Copier après la connexion

Courgez tôt, courgez souvent

Si votre branche comprend un certain nombre de commits de refactoring, envisagez de les fusionner et de les écraser avant d'effectuer un travail supplémentaire sur votre projet. Cela permet au refactoring d'être représenté comme un seul commit dans l'historique plus large tout en restant séparé du travail du projet.

Cela isole davantage les risques des différentes tâches dans des entrées d'historique distinctes et encourage une durée de vie des branches plus courte, donc

Conclusion

Il faudra peut-être s'y habituer si vous n'êtes pas habitué au style, mais de petits commits peuvent aider à améliorer la qualité de votre code et votre processus de développement.

Entraînez-vous à créer des commits plus petits. Comme presque tout le contrôle de version, le résultat de votre travail aujourd'hui se traduit par des avantages pour vous-même et pour les autres, mais ce jour peut arriver plus tôt que prévu.

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!