27 conseils essentiels pour les utilisateurs de Git et GitHub

Bien que les utilisateurs de Git aient le choix entre des dizaines de guides de démarrage et que GitHub propose un certain nombre de guides, il n'est toujours pas facile de trouver une collection de conseils utiles pour les développeurs qui souhaitent travailler plus intelligemment avec Git et GitHub. Corrigeons ça.

Pour ceux d'entre vous qui ne connaissent pas Git ou GitHub, les prochains paragraphes vous donneront suffisamment d'informations pour comprendre les astuces. Nous listerons une douzaine de ressources utiles à la fin de cet article.

Git est un système de contrôle de version distribué, initialement écrit par Linus Torvalds en 2005 pour et avec l'aide de la communauté du noyau Linux. Je ne suis pas ici pour vous vendre sur Git, donc je vous épargnerai le discours sur sa rapidité, sa petite taille, sa flexibilité et sa popularité, mais sachez que lorsque vous clonez un dépôt Git («repo», en abrégé) , vous obtenez l'historique complet des versions sur votre propre ordinateur, et pas seulement un instantané d'une branche à la fois.

Git a commencé comme un outil de ligne de commande, digne de son origine dans la communauté du noyau Linux. Vous pouvez toujours utiliser la ligne de commande Git, si vous le souhaitez, mais ce n'est pas obligatoire. En particulier, si vous utilisez GitHub comme hôte, vous pouvez utiliser le client gratuit GitHub Desktop sur Windows ou Mac. D'autre part, la ligne de commande Git fonctionnera pour n'importe quel hôte, et elle est préinstallée sur la plupart des systèmes Mac et Linux.

Vous seul pouvez décider si vous êtes le plus à l'aise avec la ligne de commande ou un client natif avec une interface utilisateur graphique. Si vous aimez une interface graphique, en plus du client GitHub (Windows et Mac), vous pouvez envisager SourceTree (Windows et Mac, gratuit), TortoiseGit (Windows uniquement, gratuit) et Gitbox (Mac uniquement, 14,99 $). Ou vous pouvez utiliser un éditeur ou un IDE qui supporte Git en interne (voir astuce n ° 11).

Astuce Git / GitHub n ° 1: Clonez presque tout

Il existe de nombreux projets intéressants disponibles à partir de GitHub et d'autres référentiels publics Git que vous pouvez cloner librement sur votre propre ordinateur. Pourquoi voudriez-vous faire ça? Une des raisons est d'apprendre quelque chose sur le style de codage, la pratique et les outils dans une langue d'intérêt, y compris le style de commentaire du journal de validation (voir conseil n ° 4). Une deuxième raison est d'apprendre comment un projet donné atteint ses objectifs. Une troisième raison, si la licence vous permet à la fois de le faire et d'avoir un sens pour vos besoins, serait d'intégrer le projet dans votre propre entreprise ou produit. Vérifiez à nouveau la licence, en passant, afin de ne pas rencontrer de problèmes de conformité plus tard.

La définition de à git clonepartir de la page de manuel:

Clone un référentiel dans un répertoire nouvellement créé, crée des branches de suivi à distance pour chaque branche du référentiel cloné (visible à l'aide de git branch -r), et crée et extrait une branche initiale qui est dérivée de la branche actuellement active du référentiel cloné.

Après le clonage, un plain git fetchsans arguments mettra à jour toutes les branches de suivi à distance, et un git pullsans arguments fusionnera en plus la branche maître distante dans la branche maître actuelle, le cas échéant.

Astuce Git / GitHub n ° 2: tirez fréquemment

L'un des moyens les plus simples de créer un désordre avec Git (et en fait, avec n'importe quel système de contrôle de version) est de permettre aux fichiers de se désynchroniser. Si vous le faites git pullfréquemment, vous maintiendrez votre copie du dépôt à jour et vous aurez la possibilité de fusionner votre code modifié avec les modifications des autres alors que la fusion est facile à comprendre et à réaliser - idéalement, lorsqu'elle est si simple qu'elle peut être fait automatiquement. Un corollaire de cette astuce est de surveiller l'état de votre projet. De nombreux clients Git vous montreront automatiquement quand vous devez mettre à jour pour rester à jour.

Astuce Git / GitHub n ° 3: Commit tôt et souvent

Un commit est une mise à jour granulaire d'un projet, qui inclut une ou plusieurs modifications d'un ou plusieurs fichiers. Considérez-le comme un enregistrement d'une unité de travail achevée, qui peut être appliquée ou supprimée du projet dans son ensemble logique. Validez chaque modification logique que vous effectuez, avant même de la tester. Les validations s'appliquent uniquement à votre référentiel local. Voir les conseils n ° 4 et 5 pour les corollaires de ce conseil.

La définition de à git commitpartir de la page de manuel:

Stocke le contenu actuel de l'index dans une nouvelle validation avec un message de journal de l'utilisateur décrivant les modifications.

Astuce Git / GitHub n ° 4: commentez vos commits comme vous voudriez que d'autres commentent les leurs

Il existe 10 types de codeurs: ceux qui commentent leurs validations et ceux qui ne le font pas. (Ancienne blague. Indice: quelle base est-ce que j'utilise?)

J'admets volontiers être un adepte des bons messages de journal de validation. J'ai configuré mes référentiels pour exiger des messages pour chaque commit, et je suis connu pour envoyer des messages de fin de soirée ennuyés lorsque les commits arrivent avec des journaux de l'ordre de «xx». Si vous êtes le genre de développeur qui pense (1) que le code doit parler de lui-même et (2) que les commentaires en ligne sont bien plus importants que les journaux de modifications, essayez de cloner un référentiel que vous n'avez jamais vu auparavant et d'identifier le commit récent qui peut avoir causé le dernier problème publié sans lire tout le code. Comme vous pouvez le voir, des journaux de validation précis sont deux fois plus bons.

Astuce Git / GitHub n ° 5: Push lorsque vos modifications sont testées

Le pire bogue lié à Git que j'aie jamais eu la malchance de connaître s'est produit lorsqu'une société de sous-traitance a quitté Subversion mais n'a pas formé ses développeurs sur la différence entre le contrôle de source distribué et le contrôle de source centralisé. Environ un mois plus tard, le projet a développé des bugs étranges que personne ne semble pouvoir retrouver. Lors des réunions debout quotidiennes, les développeurs responsables de la zone de l'application qui se comportait mal protestaient: «J'ai corrigé cela il y a deux semaines!» ou accusez un autre développeur de ne pas prendre la peine de retirer les modifications qu'il avait si soigneusement enregistrées.

Finalement, quelqu'un a identifié le problème et a enseigné à tous les développeurs comment et quand effectuer pushleurs commits: en bref, chaque fois que les commits sont testés avec succès dans une version locale. Ensuite, la société a organisé un festival de fusion de deux jours avant de pouvoir créer et déployer le produit intégré mis à jour.

Astuce Git / GitHub n ° 6: branchez librement

L'un des plus grands avantages de Git par rapport à d'autres systèmes de contrôle de version est que la fusion fonctionne généralement bien, du moins en partie parce que Git choisit automatiquement le meilleur ancêtre commun à utiliser pour une fusion. La plupart des développeurs de logiciels doivent commencer à créer des branches dans leurs projets plus souvent. Cela devrait être un événement quotidien de routine, pas le sujet d'une réunion stratégique angoissée à toutes les mains. Il est probable que, lorsque le projet de branche est terminé, accepté et prêt à passer au projet principal, la fusion ne présentera pas de problèmes insurmontables.

Je sais que cela nécessite quelques ajustements, surtout si vous êtes coincé dans une entreprise qui contrôle le code source avec CVS. Mais essayez-le. C'est bien mieux que d'avoir des clients qui voient accidentellement votre code expérimental inachevé lorsque le projet de tronc doit être publié à cause d'un bug de rupture. (Cet article explique bien le branchement et la fusion de base.)

Astuce Git / GitHub n ° 7: fusionnez soigneusement

Bien que les fusions avec Git fonctionnent généralement bien, si vous les faites sans réfléchir, vous pouvez parfois rencontrer des difficultés. La première étape consiste à vous assurer que vous n'avez pas de modifications non validées. Depuis la git mergepage de manuel:

Avant d'appliquer des modifications extérieures, vous devez mettre en forme votre propre travail et le valider localement, afin qu'il ne soit pas écrasé en cas de conflit. Voir aussi git-stash.

Voir également le conseil n ° 8.

Même si tout va au sud pendant un git merge, vous n'êtes pas arrosé:

Si vous avez essayé une fusion qui a entraîné des conflits complexes et que vous souhaitez recommencer, vous pouvez récupérer avec git merge —abort.

La commande suivante git mergeest généralement git mergetool, en supposant que vous aimiez utiliser une interface graphique pour la fusion. Si vous préférez la méthode vieille école, vous pouvez éditer les fichiers en conflit avec votre éditeur de programmation favori, supprimer complètement les <<<<<<<, =======et les >>>>>>>lignes, enregistrez les fichiers révisés, et git addchaque fichier que vous fixe.

Astuce Git / GitHub n ° 8: Cacher avant de changer de branche

Le flux de travail d'un développeur de logiciel est rarement linéaire. Les utilisateurs ont le culot de signaler les bugs, les managers ont l'audace de prioriser les tickets autres que celui sur lequel vous avez choisi de travailler, et vous pourriez vous-même changer d'avis sur ce que vous voulez faire.

Vous voilà, avec trois fichiers validés pour une version et un quatrième fichier dans un état modifié mais non fonctionnel. (La git statuscommande vous dira tout cela si vous ne vous souvenez pas où vous étiez.) Tout à coup, vous devez travailler sur un correctif de bogue dans une version de production. Vous devez changer de succursale pronto, mais vous ne pouvez pas. Votre répertoire de travail est sale et vous avez deux heures de travail que vous ne voulez pas perdre.

Entrez git stash. Voilà! Vous avez maintenant toutes vos modifications stockées dans une branche WIP (work in progress) et vous pouvez basculer vers la branche de production à partir de votre répertoire propre. Lorsque vous avez terminé, revenez là où vous étiez git stash apply.

Astuce Git / GitHub n ° 9: Utilisez des gists pour partager des extraits et des pâtes

Les «gists» de GitHub - extraits de code partagés - ne sont pas une fonctionnalité Git, mais ils utilisent Git. Tous les éléments essentiels sont des dépôts Git et GitHub Gist facilite leur partage. Vous pouvez rechercher dans Gist des informations générales publiques par sujet, langage de programmation, statut fourchu et statut étoilé. Vous pouvez également créer des informations essentielles et les partager par URL.

Astuce Git / GitHub n ° 10: Explorez GitHub

De nombreux projets open source intéressants ont des référentiels sur GitHub. Explorer GitHub fournit une interface de navigation pour en trouver certains, mais il est surtout plus facile de taper quelques lettres du nom du projet dans la zone de recherche pour trouver ses dépôts. Par exemple, saisissez jqou backou angpour trouver trois des principaux frameworks JavaScript open source.

Astuce Git / GitHub n ° 11: Contribuez à des projets open source

Tant que vous parcourez des projets open source, pourquoi ne pas y contribuer? Ce n'est pas aussi difficile que vous pourriez le penser et vous apprendrez beaucoup. Par exemple, vous pouvez cloner le projet jquery / jquery (jQuery Core) et parcourir README.MD. Près du sommet, vous verrez:

Dans l'esprit du développement de logiciels open source, jQuery encourage toujours la contribution du code communautaire. Pour vous aider à démarrer et avant de vous lancer dans l'écriture de code, assurez-vous de lire attentivement ces instructions de contribution importantes ...

Cela est suivi de trois liens. Le premier des trois vous permettra de démarrer assez rapidement. Tous les projets open source ne présentent pas le plan si clairement, mais ils essaient tous.

Comprenez la différence entre être contributeur et committer. Un contributeur a signé les accords requis et a mis une contribution à la disposition du projet. Un commetteur est habilité à engager réellement la contribution offerte dans le référentiel du projet. Comme il y aura un délai pendant qu'un committer teste votre contribution et que vous ne voudrez pas lier votre branche principale, vous devez effectuer vos modifications dans une autre branche (voir astuce n ° 6) avant d'envoyer une pull request (voir astuce Non 16).