fonction.jpg
Accueil » Actualités » 7 conseils pour maîtriser Git

7 conseils pour maîtriser Git



Aujourd’hui, chaque développeur devrait utiliser un système de contrôle de révision. Git est le plus populaire et il n’est pas difficile de se lancer.

Une chose que tous les développeurs de logiciels embarqués et, espérons-le, tous les développeurs de logiciels généraux ont en commun, c’est qu’ils utilisent un système de contrôle de révision pour gérer leurs logiciels. Il existe différents systèmes de contrôle de révision, mais le système le plus populaire aujourd’hui est Git. Si vous n’avez jamais utilisé de système de contrôle de révision ou si vous commencez tout juste à utiliser Git, voici quelques trucs et astuces pour maîtriser Git qui vous aideront à devenir rapidement opérationnel.

Adobe Stock240_F_321266283_9dPFvGoU8niQemU51akfgYBmsVpT8nH7.jpg

Astuce #1 – Commencez à utiliser Git à partir de la ligne de commande

Lorsque j’ai commencé à utiliser Git, j’ai commencé à utiliser une interface utilisateur graphique (GUI) qui a complètement abstrait les détails de Git et ce qui se passait dans les coulisses. C’était certainement pratique, mais le problème était que je n’avais aucune idée de ce qui se passait dans les coulisses. Le manque de compréhension de ces détails a créé des lacunes dans mes connaissances qui ont rendu la gestion du référentiel plus difficile.

Au début, la meilleure chose à faire, même si cela sera plus lent au début, est d’utiliser Git via la ligne de commande. Cela oblige un développeur à bien comprendre Git, son fonctionnement, les commandes et les connaissances en coulisses. Ce n’est qu’alors qu’il est vraiment logique pour un développeur d’abstraire ces détails et de passer à une interface graphique.

Astuce #2 – Entraînez-vous avec un projet de test

Les développeurs peuvent apprendre Git à la volée sur un projet, mais la meilleure façon d’apprendre est de prendre du temps et de créer un projet de test. Un projet de test offre plusieurs avantages à l’équipe de développement tels que :

  • Expérimenter le branchement
  • Expérience de fusion de succursales
  • Travailler dans un référentiel avec plusieurs développeurs
  • Intégration de l’intégration continue et des tests
  • Déterminer le flux de travail et comment résoudre les problèmes inévitables

Un projet de test n’a pas besoin d’être compliqué. Il ne peut s’agir que de quelques fichiers texte dans lesquels les développeurs collent du texte aléatoire. Les développeurs peuvent jouer avec leur organisation de projet, savoir comment ignorer des types de fichiers spécifiques tels que les fichiers objets et même créer des sous-modules.

Astuce n°3 – Utilisez des sous-modules

Un sous-module Git est essentiellement un autre référentiel Git inclus dans un autre référentiel. Par exemple, je travaillais récemment sur un projet qui utilisait une bibliothèque Microchip Harmony pour tous les pilotes de bas niveau et une certaine prise en charge de middleware. Plutôt que de créer un référentiel de projet unique, j’ai créé un référentiel pour stocker la bibliothèque Microchip Harmony, puis un autre référentiel pour mon code d’application. La bibliothèque Microchip Harmony a été incluse dans le référentiel d’applications en tant que sous-module.

Le sous-module dans ce cas présente également quelques avantages supplémentaires. Tout d’abord, je peux utiliser le sous-module sur plusieurs référentiels. Si je travaille sur plusieurs projets utilisant Microchip Harmony, je n’ai pas besoin de conserver des copies séparées des bibliothèques. J’ai juste le référentiel Microchip Harmony que j’ajoute en tant que sous-module à mes référentiels d’applications. Deuxièmement, lorsque je récupère mon application et apporte des modifications, par défaut, le sous-module ne sera pas inclus sans commandes ou options de commande supplémentaires. Ceci est utile car si j’avais tout vérifié dans un seul référentiel, il faudrait plusieurs minutes à git pour rechercher les modifications dans mon projet en raison du nombre de fichiers contenus dans la bibliothèque Microchip Harmony.

Astuce n°4 – Tirez parti de l’interface graphique Git pour simplifier la gestion des logiciels

J’ai toujours trouvé le travail à partir d’un terminal un peu fastidieux. Les terminaux offrent un niveau de contrôle supplémentaire que de nombreux développeurs peuvent vouloir utiliser, mais une fois que vous comprenez ce que Git fait dans les coulisses et ses capacités, il est souvent habituel et plus rapide d’abstraire ces détails et d’utiliser un outil graphique pour interagir avec le référentiel. Il existe de nombreux outils d’interface graphique que les développeurs peuvent utiliser. Les deux que j’utilise le plus sont SourceTree et TortoiseGit. SourceTree est un outil fourni gratuitement par Atlassian qui fonctionne avec les machines Mac et Windows. TortoiseGit est pour Windows et intègre le répertoire dans l’explorateur Windows, ce qui peut être très pratique.

Astuce n°5 – Développer et/ou adopter un flux Git standard

Ce qui est bien avec Git, c’est qu’il y a pas mal de workflows qui ont déjà été développés et utilisés par les développeurs depuis des années. Lorsque vous commencez, vous pouvez essayer de comprendre ce qui fonctionne pour vous par essais et erreurs, ou vous pouvez utiliser un flux Git standard. Il existe plusieurs flux de travail différents qui sont devenus très populaires, tels que :

  • Flux de travail Gitflow
  • Flux de travail de fourche
  • Flux de travail de branche de fonctionnalité

Personnellement, j’utilise généralement un workflow de branche de fonctionnalité. Dans ce cas, un développeur crée une branche à partir de la ligne principale qui est utilisée pour développer une fonctionnalité d’application spécifique telle qu’un pilote ADC, une fonctionnalité anti-rebond de bouton, etc. D’autres développeurs travaillant sur le projet créent également des branches pour eux-mêmes pendant qu’ils développent leur caractéristiques. Une fois la fonctionnalité terminée, elle est fusionnée dans la ligne principale. Cela présente plusieurs avantages importants tels que:

  • La ligne principale ne contient jamais de code expérimental ou cassé
  • La ligne principale peut être utilisée par un serveur d’intégration continue
  • Chaque développeur travaille à partir de sa propre branche, minimisant l’impact du travail effectué par d’autres développeurs

Vous pouvez en savoir plus sur les différents GitFlows à partir du didacticiel officiel d’Atlassian à l’adresse https://www.atlassian.com/git/tutorials/comparing-workflows.

Astuce n°6 – Valider le code avec des commentaires utiles

Lors de la validation du code dans un référentiel, les développeurs doivent inclure des commentaires utiles qui leur permettent de revenir facilement dans le référentiel et de comprendre ce qu’il y a dans cette version du code. Lorsque je crée une branche, je nomme la branche quelque chose d’utile comme FEATURE_ADC. Lorsque je valide ce code ou que je fusionne le résultat avec la ligne principale, il y a plusieurs informations que je m’assure d’inclure dans mon journal de commentaires :

  • Le numéro de version du logiciel et/ou de la fonctionnalité
  • Quels changements ont été apportés
  • Tout problème connu avec cette version
  • Observations générales

Je vais souvent inclure une section pour chacun de mes commentaires et remplir chaque section. Par exemple, dans la section des modifications, je commenterai souvent ce que j’ai ajouté, supprimé et mis à jour. Dans la section des problèmes, je peux inclure des notes indiquant que je dois ajouter une gestion des erreurs ou que les tests ne couvrent que 50 %, ou toute note qui me permet de savoir quel travail supplémentaire je dois faire. Je peux également inclure tout nouveau bogue découvert que je n’ai pas corrigé dans ce commit. Enfin, je peux laisser des commentaires généraux sur le code tels que la nécessité de mettre à jour la documentation, une idée d’amélioration, etc.

Les commentaires peuvent être extrêmement utiles pour identifier ce qu’il y a dans cette version, mais ils peuvent également être utiles pour réviser après le déjeuner pour se rappeler où vous vous êtes arrêté et ce qui doit être abordé ensuite dans le logiciel.

Astuce n°7 – Identifiez un bon manuel de référence

Le dernier conseil pour aujourd’hui est que chaque développeur a besoin d’une bonne référence Git. Pour la plupart, il est facile d’effectuer simplement une recherche dans votre moteur de recherche préféré pour déterminer quelle était la commande pour initialiser un sous-module ou pour ranger vos modifications actuelles ou rebaser sur la ligne principale actuelle. Pour une raison quelconque, j’aime aussi toujours garder une référence physique sous forme de livre parfois. J’ai découvert que même si je peux trouver quelque chose sur Internet assez rapidement, un bon livre fonctionne tout aussi bien et donne à mes yeux une pause après avoir regardé un écran. Pour Git, j’ai trouvé que « Contrôle de version avec Git » de Jon Loeliger et Matthew McCullough était une bonne référence et également un bon livre pour les débutants qui souhaitent obtenir une compréhension approfondie de la configuration et de l’utilisation de leurs référentiels Git. Je soupçonne que la plupart des développeurs ne font que rechercher sur le Web au besoin, mais comme Git effectue une tâche si importante pour les développeurs, nous devrions vraiment tous creuser plus profondément.

Conclusion

Aujourd’hui, chaque développeur devrait utiliser un système de contrôle de révision. Git est le plus populaire et il n’est certainement pas difficile de commencer. Certaines nuances peuvent certainement être difficiles pour les débutants. Dans l’article d’aujourd’hui, nous avons exploré quelques conseils simples pour commencer qui devraient aider le lecteur à se mettre rapidement à jour.

Publications similaires