Sans système de contrôle de version, il est pratiquement impossible de gérer le code source. Vous pouvez être un développeur de logiciels en C, C#, Java ou tout autre langage, mais vous avez besoin d'un contrôle de version. Le meilleur et l'un des systèmes de contrôle de version les plus populaires est Git.
Git est un système de contrôle de version distribué (VCS) open source gratuit utilisé par de nombreuses petites et grandes entreprises. Ses fonctionnalités sont impressionnantes et plusieurs milliers de supporters de Git ajoutent volontiers d'autres pratiques et astuces pour rendre la gestion du contrôle des sources plus productive.
Actuellement, vous pouvez utiliser plus de 35 bonnes pratiques Git et de nombreux conseils. Cependant, cet article se concentrera sur les 11 meilleurs conseils et pratiques Git optimaux pour les débutants.
Je vais commencer par ma préférée de tous les temps - la technique APRÈS. APRÈS signifie :
- Un tomic Commits
- F commits fréquents
- T modifications les plus importantes avant l'envoi
- E normes en vigueur
- R efactorisation.
Commissions atomiques
Un commit atomique est un commit unique basé uniquement sur un contexte. J'entends par là un sujet unique en termes de contexte :fonction, correction de bogue, refactorisation, mise à jour. Si toutes les modifications de votre projet se déroulent en un seul commit, c'est la voie monolithique ou le commit spaghetti .
Commits fréquents
Les meilleures pratiques de Git affirment que les commits ne doivent pas être basés sur une base temporelle (horaire, quotidienne, etc.). Au lieu de cela, vous devez vous engager en fonction d'une fonction. Par conséquent, vous devez vous engager chaque fois que vous ajoutez une modification digne d'être validée.
Avez-vous intégré une technique de travail ? Validez.
Avez-vous corrigé la faute de frappe ? Validez.
Avez-vous corrigé un fichier d'indentation incorrect ? Validez.
Dès lors que le dévouement est essentiel, il n'y a rien de mal à faire des ajustements mineurs.
Testez vos modifications avant de pousser
Dans Git, vous pouvez travailler seul ou en équipe en collaboration. Lorsque vous validez votre code, vous travaillez avec votre référentiel local, et lorsque vous transférez vos modifications, vous travaillez avec le référentiel distant et partagez vos modifications de code avec l'équipe.
Tester vos modifications avant de les pousser est un must. Si vous poussez le code cassé, votre équipe peut se retrouver dans une position de blocage à cause de l'erreur. Par conséquent, testez toujours vos modifications localement avant de les transmettre à la télécommande.
Appliquer les normes
Dans tout projet, les normes sont cruciales. Ils accélèrent l'efficacité globale et minimisent les erreurs et les retards. Notez les deux principes simples que vous pouvez toujours appliquer dans votre équipe :
- Utilisez un fichier gitignore :il permet à Git de savoir que certains fichiers doivent être ignorés, car ils ne font pas partie de votre code. Cela aide également à maintenir votre dépôt en bonne santé.
- Ajoutez un commentaire approprié à chaque commit. Il est utile pour les développeurs et sert de documentation.
La refactorisation n'est pas une fonctionnalité
Pour les développeurs, la refactorisation du code est courante. Il est également bénéfique pour de nombreuses raisons, telles que :
- Rendre le code de l'équipe lisible.
- Réduire la sophistication.
- Rendre votre code source plus maintenable, etc.
Le pire, cependant, est de refactoriser et d'ajouter une nouvelle fonctionnalité dans le même commit.
Si vous voulez faire du refactoring, cela devrait être un commit séparé. Et si vous travaillez sur une nouvelle fonctionnalité, elle doit figurer dans un commit particulier.
Ces pratiques compilent la technique APRÈS. Passons maintenant à d'autres conseils utiles pour travailler avec Git.
Cloner une branche
Parfois, vous devez cloner une branche particulière du référentiel distant, pas le référentiel entier. Dans ce cas, Git Remote Add est la solution :
git remote add -t
Définir et réinitialiser l'auteur
Pour utiliser Git, vous devez définir votre nom et votre adresse e-mail après l'avoir téléchargé. Les données seront attachées à chaque commit que vous faites. Par conséquent, vous ne pourrez pas créer de commits sans lui.
git config –global user.name "Votre nom"
git config –global user.email [email protected]
Si, pour une raison quelconque, vous avez besoin de réinitialiser votre nom ou votre adresse e-mail, voici la marche à suivre :
git commit –amend –reset-author –no-edit
Optimiser le dépôt
Si un référentiel comprend plusieurs centaines d'objets, il peut y avoir de nombreux objets inutiles. Il est possible de les supprimer avec une commande spécifique - une commande de récupération de place qui nettoiera votre référentiel local.
Voici la syntaxe :git gc
Obtenez votre guide Git
Il est toujours préférable de connaître les commandes git. Git propose une commande distincte à cet effet, la commande git help :
git help -g
En l'exécutant, vous pouvez accéder et lire toutes les commandes git disponibles. La commande est particulièrement importante lorsque vous apprenez Git.
Archives Git
La commande Git Archive est un utilitaire de ligne de commande Git qui génère un fichier d'archive comme des commits, des branches ou des arborescences à partir des références Git répertoriées. Les arguments supplémentaires qui modifieront la sortie de l'archive sont approuvés par l'archive git.
archive git –format=tar HEAD
Cette commande construit une archive à partir de la référence HEAD actuelle du référentiel lorsqu'elle est exécutée. C'est un utilitaire précieux pour créer des packages de référentiel git distribués. Remarque :Il autorise plusieurs formats de sortie dans l'archive de Git qui peuvent utiliser une compression supplémentaire.
Connaître le dossier .git
Le dossier .git contient toutes les informations de contrôle de version nécessaires à votre projet et toutes les informations de validation, l'adresse du référentiel distant, etc. Il fournit également un journal qui stocke votre historique de validation afin que vous puissiez revenir à l'historique.
Le dossier .git est le répertoire créé lorsque vous effectuez le git init ou git clone. Cette « chose » crée un référentiel « git » pour votre projet. Sans cela, le projet est local - pas un projet git, et vous ne pouvez appliquer aucune opération git.
La suppression du dossier .git ne supprime aucun autre fichier faisant partie du référentiel git. Cependant, il ne sera plus sous contrôle de version. Par conséquent, vous ne devez pas supprimer ce dossier.
Conclusion
Git, étant un vaste système avec plusieurs centaines de milliers de supporters, s'améliore constamment. Les développeurs ajoutent de nouvelles options et rendent la coopération des utilisateurs beaucoup plus efficace, et l'exécution des tâches plus fluide et plus rapide.
De nombreuses solutions logicielles pour valider les modifications et travailler avec des référentiels distants. Parmi eux, il convient de mentionner dbForge Source Control, un complément SSMS multifonctionnel. La fonctionnalité Ifs vous permet de travailler avec Git, ainsi qu'avec des systèmes tels que SVN, TFS et Microsoft Azure DevOps.
J'espère que cet article vous a fourni des connaissances essentielles sur les astuces et les meilleures pratiques de git, afin que vous puissiez augmenter votre productivité. Merci d'avoir lu, et j'espère que cet article vous aidera dans votre travail.
