Git Best Practices – Comment tirer le meilleur parti de (g)it

Pull, Fetch, Commit, Push, Merge, Rebase – ces termes ont-ils déjà réussi à faire leur chemin dans votre vie quotidienne ? Lorsque Linus Torvalds a créé sa toute première version de Git, il l'a décrit comme "le stupide tracker de contenu". Avance rapide jusqu'à aujourd'hui, ce logiciel open source gratuit est désormais le système de contrôle de version le plus populaire.

Qu'est-ce que Git ?

N'aimeriez-vous pas pouvoir remonter le temps parfois, afin d'avoir pu prendre une meilleure décision ou faire les choses différemment ? Eh bien, dans le monde de la technologie et du codage, vous le pouvez. Git est un système de contrôle de version distribué open source qui enregistre les versions de votre précieux code chaque fois que vous y apportez des modifications/ajouts. Ainsi, chaque fois que vous avez besoin de revenir en arrière, il vous suffit de choisir la version de travail et le tour est joué ! Git permet également de travailler sans interruption au sein des équipes, car les développeurs travaillent simultanément sur leurs copies locales individuelles. Chaque changement par chaque membre de l'équipe est suivi, maintenant ainsi la transparence dans un flux organisé. Alors, qu'est-ce que GitHub ? GitHub est un service d'hébergement de référentiel pour Git qui possède également de nombreuses fonctionnalités pour optimiser votre système de contrôle de version.
Flux de travail Git

Chaque organisation a un workflow Git différent. Le workflow Git le plus réussi est celui qui donne à votre équipe suffisamment d'espace pour la productivité tout en maximisant l'efficacité de leurs sorties. Il doit être évolutif avec la taille de votre équipe et doit minimiser le nombre de conflits pouvant survenir. Le workflow Git centralisé est la base sur laquelle sont construits d'autres workflows Git, comme le workflow de branchement de fonctionnalités, le workflow de fork, le workflow Gitflow, etc. Un workflow doit être planifié pour améliorer et compléter la culture de votre organisation. À chaque équipe, son propre workflow Git.

Pourquoi utiliser Git ?

1. L'architecture distribuée

Contrairement aux systèmes de contrôle de version centralisés qui obligent les développeurs à accéder au référentiel central unique pour pouvoir « extraire » et valider les modifications apportées aux fichiers individuels, Git suit une approche distribuée. Dans l'architecture distribuée, chaque développeur dispose de ses propres copies locales de l'intégralité du référentiel central, ce qui lui permet de travailler hors ligne, d'accéder à l'historique complet des révisions et de faciliter la création de branches et la fusion.

2. Des performances puissantes

Le branchement, la fusion, la validation, etc. sont vraiment faciles et rapides avec le workflow Git en raison de ses algorithmes intelligents de connaissance approfondie qui comprennent les modèles d'accès au T.

3. C'est sécurisé

Git stocke tout le contenu des fichiers, y compris les relations entre les versions et les répertoires, en utilisant de manière cryptographique un SHA1 comme algorithme de hashtag. Tout changement de code accidentel ou malveillant est entièrement traçable.

4. Open source

Étant open-source, Git est gratuit, bénéficie d'un bon support communautaire, d'un contrôle continu de la qualité et est soutenu par une multitude de documentation et de tutoriels pour les apprenants.

5. Des versions plus rapides

Le développement distribué de Git, la création de branches et la création faciles de nouvelles fonctionnalités encouragent les développeurs à apporter des modifications plus fréquentes dans un workflow agile

Bonnes pratiques pour Git

• Nouveau projet? Nouveau référentiel

Il est tout simplement logique de créer un nouveau dépôt pour chaque nouveau projet sur lequel vous souhaitez commencer à travailler. Une fois cela fait, poussez-le vers GitHub.

• Nouvelle fonctionnalité? Se ramifier

Maintenant que vous avez créé un nouveau projet, que diriez-vous de créer de nouvelles fonctionnalités Git ? Git Branching vous permet de créer et de gérer un flux de travail organisé au sein de votre référentiel. Les membres de l'équipe peuvent se voir attribuer diverses branches Git, ce qui leur permet de travailler simultanément mais de manière isolée. Donnez toujours un sens à votre branche git afin que les autres sachent exactement sur quoi vous travaillez.

• Commencez votre journée en restant à jour

Toujours « rebase » ou obtenez la dernière version la plus récente de votre projet (maître) avant de commencer à travailler sur les fonctionnalités que vous avez créées/attribuées. Vous ne voulez pas apporter de modifications aux fichiers obsolètes.

• Avoir des points de contrôle périodiques

Ne sauvegardez pas vos commits pour un grand changement. « Commettez » fréquemment de petits changements afin que le code soit plus facile à comprendre pour vous et les membres de votre équipe. Le retour en arrière et le suivi sont également plus faciles lorsque les changements sont petits et fréquents.

• Rangez votre travail

Souvent, vous pouvez rencontrer des situations où vous travaillez sur une branche Git mais vous vous souvenez soudainement que vous avez besoin de travailler sur une autre branche mais que vous ne voulez pas « valider » ces changements à moitié effectués. Ou vous voudrez peut-être simplement une copie de travail propre. "git stash" à la rescousse. Le stockage vous permet d'enregistrer vos modifications inachevées sur une pile où vous pouvez revenir à tout moment !

• Écraser les commits

Avoir moins de commits dans votre historique facilite la surveillance et le suivi de vos erreurs. Si vous souhaitez conserver un historique des commits propre, celui-ci est fait pour vous. Écrasez et fusionnez tous vos commits en un seul lorsque la pull request est fusionnée.

• Valider des messages

Fournissez toujours des informations claires et compréhensibles dans votre message de validation. Commencez par rédiger un bref résumé de vos modifications, laissez une ligne vide, puis poursuivez avec une description détaillée du changement. Vous ne voulez pas que votre historique de commit ressemble à ça :/

• Ne changez pas l'histoire

Une fois que vous avez validé vos modifications dans le référentiel, ne revenez pas en arrière et modifiez l'historique. Bien que Git vous permette de faire cela et de réécrire l'histoire publique, ce n'est jamais une bonne pratique de le faire. Tant pour vous que pour votre équipe.

• Appliquer un correctif Git

Parfois, lorsque vous n'avez pas d'accès en écriture au référentiel mais que vous souhaitez tout de même corriger un bogue, appliquez un correctif Git. N'oubliez jamais de cloner le référentiel maître, puis de créer une branche pour la nouvelle fonctionnalité. Lorsque vous avez votre fichier .patch prêt, prévisualisez-le toujours et effectuez un essai à sec pour vérifier les erreurs. Git applique le correctif (git apply -R path/file.patch) une fois terminé. N'oubliez pas de tester et de vérifier

• Ne laissez pas les demandes de retrait trop longtemps

Une requête « pull » ouverte peut créer des conflits tôt ou tard. Ne les laissez pas sans surveillance pendant plus de 2 jours. Vérifiez toujours le code et s'il peut être déployé, fusionnez la demande d'extraction. Cela accélérera non seulement le processus d'expédition, mais évitera également les conflits de code.

• Mieux s'organiser avec les outils de gestion de projet

Si vous avez utilisé des outils de gestion de projet comme Redmine, il est recommandé de les utiliser avec Git pour pouvoir mieux gérer plusieurs membres de l'équipe et leurs tâches. La création de vos branches Git avec la tâche Redmine comme nom est l'une des meilleures pratiques Git car elle permet une meilleure transparence et une meilleure organisation.

• GitLab CI/CD

L'utilisation d'un outil d'intégration continue/déploiement continu comme celui-ci vous permet de tester et de vérifier les bogues et les erreurs et d'assurer la compatibilité avec les normes de code. Ces travaux sont exécutés une fois que le code est transmis au serveur de transfert.