Git est un logiciel de gestion de versions décentralisé, Ce logiciel est devenu indispensable dans tout environnement de développement, qu’il soit un environnement individuel ou bien un projet collectif.
Ce logiciel nous donne la possibilité de contrôler les versions de notre code, par suite si nous avons cassé quelque chose on peut toujours revenir vers la version précédente fonctionnelle en des cliques/commandes simples, ainsi que le suivi des modifications sur chaque ligne (qui a modifié et quand).
Cet article représente un guide des bonnes pratiques pour utiliser Git d’une façon plus optimale 😉 .
À qui s’adresse ce guide
Ce guide s’adresse à tous les membres de l’organisation de développement logiciel qui souhaitent améliorer le flux de travail et la productivité des développeurs, ainsi que la qualité et la sécurité du code.
Les personnes chargées d’élaborer des pratiques et des politiques standard à l’échelle de l’équipe bénéficieraient grandement de ce guide, mais même si vous n’êtes pas un développeur responsable de l’application, vous trouverez ces pratiques applicables et utiles à retenir.
1 – Ne pushez pas directement vers la branche master
Quel que soit le modèle de branchement git que vous utilisez, il est toujours judicieux d’activer la protection de branche git pour empêcher les validations directes et vous assurer que votre code de branche principal est déployable à tout moment. Toutes les validations doivent être transmises au master via des pull-requests.
Pour activer cette fonctionnalité, vous pouvez suivre les étapes suivantes.
Aller dans votre projet sur Github → Settings → Branches → Branch protection rules → Add rule → Saisir le nom de la branche (ex. Master) → Cochez require pull request reviews before merging.
2 – Ne pas commiter le code en tant qu’auteur non reconnu
Parfois, vous validez du code en utilisant la mauvaise adresse e-mail et, par conséquent, GitHub montre que votre validation à un auteur non reconnu. Le fait d’avoir des validations avec des auteurs non reconnus rend plus difficile le suivi de qui a écrit quelle partie du code.
Assurez-vous que votre client Git est configuré avec la bonne adresse e-mail et lié à votre utilisateur GitHub. Vérifiez vos pull-requests lors des révisions de code pour les validations non reconnues.
3 – Définissez les propriétaires de code pour des révisions de code plus rapides
Lorsque vous traitez avec des dizaines, des centaines ou plus de repositories et de développeurs, il est presque impossible de savoir à qui appartiennent quelles parties de la base de code et doit examiner vos modifications.
Même dans les petites équipes, vous avez toujours des propriétaires de code. Par exemple, les modifications du code front-end doivent être examinées par l’ingénieur front-end.
Utilisez la fonction Propriétaires de code pour définir quelles équipes et personnes sont automatiquement sélectionnées comme réviseurs pour le référentiel.
4 – Ne divulguez pas de secrets dans le contrôle de code source
Les secrets, ou clés secrètes ou informations d’identification secrète, incluent des éléments tels que les mots de passe de compte, les clés API, les jetons privés et les clés SSH. Vous ne devez pas les enregistrer dans votre code source.
Au lieu de cela, nous vous recommandons d’injecter des secrets en tant que variables d’environnement en externe à partir d’un magasin sécurisé. Vous pouvez utiliser des outils tels que Hashicorp Vault ou AWS Secrets Manager pour ce faire.
Il existe également des outils pour analyser les secrets dans les dépôts et les empêcher d’entrer dans les dépôts.
- Git-secrets peut vous aider à identifier les mots de passe dans votre code.
- Git hooks peuvent être utilisés pour créer un hook pre-commit et vérifier chaque pull request pour les secrets.
5 – Ne pas commiter les dépendances dans le contrôle de code source
Le fait de pousser les dépendances dans votre origine distante augmentera la taille du référentiel. Supprimez toutes les dépendances de projets incluses dans vos référentiels et laissez votre gestionnaire de packages les télécharger dans chaque build. Si vous avez peur de la «disponibilité des dépendances», vous devriez envisager d’utiliser une solution de gestionnaire de référentiel binaire comme Jfrog ou Nexus Repository. Ou consultez Git-Sizer de GitHub.
6 – Ne pas commiter les fichiers de configuration locaux dans le contrôle de code source
Nous vous déconseillons fortement de commiter vos fichiers de configuration locaux dans le contrôle de version. Il s’agit généralement de fichiers de configuration privés que vous ne souhaitez pas envoyer à distance, car ils contiennent des secrets, des préférences personnelles, un historique ou des informations générales qui ne doivent rester que dans votre environnement local.
7 – Les commandes Git de base pour tout développeur:
Git pull:
Git pull permet de récupérer tous les changements sur la branche distant.
Elle prend en paramètre la branche source et la branche ciblé.
Exemple:
La commande git pull wpk preprod:master nous permet de récupérer les changement de la branche preprod du remote wpk dans la branche master du remote origin.
Git fetch:
Git fetch permet de rechercher et afficher les changements sur un remote passé en argument, qui ne sont pas présent en local, sans aucun transfert de fichiers.
Exemple:
La commande git fetch wpk permet de chercher les nouveaux changement sur le remote wpk qui ne sont pas présent en local.
Git rebase:
Git rebase permet de transférer les changements d’une branche à une autre, elle prend en argument la branche avec laquelle nous voulons rebaser.
Exemple:
La commande git rebase -i wpk/preprod permet de rebaser les commits de notre branche courant avec la branche preprod de remote wpk.
Git checkout:
Git checkout permet de déplacer d’une branche à une autre, elle prend en argument la branche cible et aussi de supprimer les modifications qui ne sont pas ajoutées.
Exemples:
- git checkout branch-A : nous permet de nous déplacer vers la branche branch-A s’elle existe.
- git checkout -b branch-B : nous permet de créer et déplacer vers la branche branch-B s’elle n’existe pas déjà.
- git checkout path/file.php : permet de supprimer tous les changements non ajoutés (unstaged) sur le fichier path/file.php.
- git checkout . : permet de supprimer tous les changements non ajoutés (unstaged) sur tous les fichiers.
Git add:
Git add permet d’ajouter les changements que nous avons fait dans nos fichiers sur la branche courante.
les deux arguments les plus importants de cette commande sont:
- git add . : permet d’ajouter tous les changements que nous avons fait.
- git add -u : permet d’ajouter les modifications sur les fichier déjà connus par git (les nouveaux fichiers ne seront pas ajoutés).
Git commit:
Git commit permet commiter les modifications que nous avons en local sur la branche courante.
Exemples:
- git commit -m “Message de commit” : permet de commiter les changements sur la branche courante, avec un message “Message de commit”.
- git commit –amend : permet de commiter les nouveaux changements sur la branche courante dans la dernière commit que nous avons créé sur la branche.
Git reset:
Git reset permet de supprimer tous les changements que nous avons fait sur la branche courante.
Exemples
- git reset –hard HEAD : permet de retourner vers la version que nous avons sur la branche master.
- git commit –amend : permet de commiter les nouveaux changements sur la branche courante dans la dernière commit que nous avons créé sur la branche.
Git push:
Git push permet d’envoyer les modifications sur un remote.
Exemple:
- git push origin branch-A : permet d’envoyer les modifications que nous avons fait sur la branche branch-A vers notre repos origin.
Git status:
- git status : permet d’afficher toutes les modifications non commités sur la branche courante.
Conclusion:
Le GIT est devenu indispensable dans toutes les équipes de développement des logiciels. Cette solution fournit plusieurs fonctionnalités étonnantes, parmi lesquelles les fonctionnalités listées au-dessus, mais il y a toujours plus de fonctionnalités à découvrir 😉 .
