10 astuces sur Git pour les développeurs

Alors qu'il y a des dizaines de guides de débutants pour Git, et GitHub, 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. En voici une.

Pour ceux d'entre vous qui ne connaissent pas Git ou GitHub, j'ai déja écrit une page ici pour parler de Git et Github pour les débutants, ou pour rejoindre un projet de développement Git avec Github, comprendre les astuces. Nous allons profiter d'une douzaine de ressources utiles à la fin de cet article.

Git est un système de contrôle de version distribué, écrit à l'origine par Linus Torvalds en 2005 pour et avec l'aide de la communauté kernel Linux. Je ne suis pas là pour vous vendre Git, alors je vais vous épargner le pitch sur la rapidité et la rapidité et la flexibilité et la popularité, mais vous devriez savoir que lorsque vous clonez un dépôt Git ( un «repo», pour les intimes) , Vous obtenez l'historique complet de la version sur votre propre ordinateur, pas seulement un instantané d'une branche à l'instant T.

Git est à la base un outil en ligne de commande, adapté à l'origine pour la communauté Linux. Vous pouvez toujours utiliser la ligne de commande Git, si vous le souhaitez, mais vous n'avez pas obligation de le faire. En effet, si vous utilisez GitHub comme hôte, vous pouvez utiliser le client gratuit GitHub sous Windows ou Mac. D'autre part, la ligne de commande Git fonctionnera pour tout hôte, et elle est préinstallée sur la plupart des systèmes Mac et Linux.

Vous seuls pouvez décider si vous êtes le plus à l'aise en utilisant 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 d'aller voir du côté de SourceTree (Windows et Mac, gratuit), TortoiseGit (Windows uniquement, gratuit) et Gitbox (Mac uniquement, 14,99 $). Ou vous pouvez utiliser un éditeur ou IDE qui prend en charge Git en interne (voir ici mon article avec Visual Studio par exemple).

Astuce Git No. 1:  On peut cloner presque tout et n'importe quoi

Il existe de nombreux projets intéressants disponibles sur GitHub et d'autres dépôts Git que vous pouvez cloner librement sur votre propre ordinateur. Quel interet? Pour apprendre le style de programmation, la pratique et les outils de code dans le langage qui vous Interesse, y compris les styles des backlogs, très intéréssants.

Une deuxième raison est d'étudier comment un projet de développement  va au bout et atteint ses objectifs.

Une troisième raison, si l'octroi de licences vous permettait de faire et d'avoir un interet pour vos besoins, vous servez d'un projet dans votre propre entreprise ou produit. Vérifier d'abord la licence , en passant, afin que vous n'arriviez pas sur les problèmes de conformité plus tard.

La définition de "Git clone" à partir de la page de manuel:

Clone un référentiel dans un répertoire nouvellement créé, crée des succursales de suivi à distance pour chaque branche dans le dépôt cloné (visible à l'aide de git branch -r) et crée et vérifie une branche initiale provenant de la branche actuellement active du dépôt cloné.

Après le clone, une extraction de git simple sans arguments mettra à jour toutes les branches de suivi à distance, et une git pull sans arguments fusionnera en outre la branche maîtresse distante dans la branche principale actuelle, le cas échéant.

Git / GitHub l'astuce n ° 2: synchroniser (puller) le code régulièrement

Une des façons les plus simples de passer à côté de l'interet de Git (et en fait, de n'importe quel système de contrôle de version) est de permettre à des fichiers de ne pas être synchronisés. Si vous gériez souvent des développements, vous conserveriez votre copie du repo à jour systématiquement, et vous auriez ainsi la possibilité de fusionner votre code modifié avec les changements des autres pus facilement et en même temps, la fusion est plus facile à comprendre et à faire, idéalement, quand c'est fait petit à petit,  ça peut se faire quasiment automatiquement. Un corollaire de cette astuce est de regarder l'état de votre projet. De nombreux clients Git vous montreront automatiquement quand vous devez mettre à jour pour tout le temps être à jour.

Une question? Posez-la ici

Aide au développement d'applications 

Git / GitHub astuce  n ° 3: Commiter dès les 1eres lignes de code, et souvent

Un commit est une mise à jour granulaire d'un projet, qui inclut une ou plusieurs modifications sur un ou plusieurs fichiers. Pensez-y comme un enregistrement d'une unité de travail terminée, qui peut être appliquée ou retirée du projet en tant qu'ensemble logique. Confirmez tous les changements logiques que vous avez terminés, même avant de le tester. Les modifications s'appliquent uniquement à votre dépôt local. Voir les conseils n ° 4 et 5 pour les corollaires à cette astuce.

La définition du commit de git  à partir de la page de manuel:

Stocke le contenu actuel de l'index dans un nouveau commit ainsi qu'un message de journal utilisateur décrivant les modifications. apportées au code

Git / GitHub astuce n ° 4: commenter votre commit comme vous voudriez que d'autres commentent le leur

Il existe 10 types de développeurs: ceux qui commentent leurs commits et ceux qui ne les commentent pas. (Vieille plaisanterie. Astuce: en quelle base on a compté là? Binaire)

J'admets volontiers être un addict des bons messages de journal de validation. J'ai mis en place mes dépôts pour exiger des messages pour chaque commit, et je déteste quand les commits sont commentés avec "xx". Si vous êtes le type de développeur qui pense ( 1) que le code devrait parler de lui-même et (2) que les commentaires en ligne sont beaucoup plus importants que les journaux de modification, essayez de cloner un dépôt comme vu précédemment et d'identifier le dernier commit qui aurait causé le dernier problème publié sans lire le code, bon courage. Comme vous pouvez le constater, des journaux de validation précis sont très importants.

Une question? Posez-la ici

Aide au développement d'applications 

Astuce Git / GitHub n ° 5: faire le "push" lorsque les modifications sont testées et validées

Le pire problème que l'on peur renconterr avecGit c'est que par exemple, une société de sous-traitance a changé de version mais n'a pas formé ses développeurs sur la différence entre le contrôle de source distribué et le contrôle centralisé des sources. Environ un mois plus tard, le projet a développé des bugs étranges que personne ne semblait avoir à compris d'où ils venaient. Lors des réunions quotidiennes de stand-up meetings Agile, les développeurs responsables du domaine de l'application qui se comportait de manière erronée protestent: «J'ai réparé cela il y a deux semaines!» Ou accusent un autre développeur de ne pas avoir appliqué les changements qu'ils avaient vérifiés si attentivement.

Finalement, quelqu'un a identifié le problème et a enseigné à tous les développeurs comment et quand pousser leurs modifications? : en bref, chaque fois que les tests sont validés en local. Ensuite, la société fait un "code freeze"  de quelques jours/heures, le temps de valider ll'ensemble de tous les commits

Astuce Git / GitHub n ° 6: créer des branches facilement et rapidement 

L'un des plus grands avantages que Git a sur certains autres systèmes de contrôle de version est que la fusion de code fonctionne relativement bien, du moins en partie parce que Git choisit automatiquement le meilleur code commun à utiliser pour une fusion. La plupart des développeurs de logiciels doivent commencer à créer des branches dans leurs projets tôt et souvent. Ce devrait être une routine, un reflexe, pas le sujet d'une réunion de stratégie angoissante pour tous. Il est probable que, lorsque le projet de la branche est complet, accepté et prêt à être mergé dans le projet principal, la fusion ne présente aucun problème insurmontable.

Je sais par experience que cela demande un certain ajustement, surtout si vous avez été coincé dans une entreprise qui contrôle le code source avec CVS. Mais essayez-le. C'est beaucoup mieux que de faire voir aux décideurs accidentellement votre code expérimental inachevé lorsque le projet doit être publié quand même mais non fonctionnel en raison d'un bug non corrigé. 

Une question? Posez-la ici

Aide au développement d'applications 

Git / GitHub Astuce n ° 7: mergez avec soin

La fusion/merge avec Git fonctionne habituellement bien, si vous les faites sans y penser, de manière automatique, vous pouvez parfois rencontrer des difficultés. La première étape consiste à vous assurer que vous n'avez aucune modification de code non commitée. 

Avant d'appliquer les changements extérieurs, vous devriez obtenir votre propre travail en bonne forme et engagé localement, de sorte qu'il ne sera pas bloqué s'il y a des conflits.

Voir git-stash

Même si tout part en cacahuète lors d'un merge, vous n'êtes pas pénalisé:

Si vous avez essayé une fusion qui a donné lieu à des conflits complexes et que vous voulez recommencer, vous pouvez récupérer avec la commande git merge -abort.

Le suivi sur merge git est généralement fait avec un merge tool git, en supposant que souhaitez utiliser une interface graphique pour le merge. Si vous préférez la bonne vieille méthode old-school-has-been, de quand votre arrière grand-mère codait en 1848 vous pouvez éditer les fichiers en conflit avec votre éditeur de texte favori, supprimer complètement les lignes <<<<<<<, ======= et >>>>>> > , enregistrez les fichiers révisés et ajouter manuellement à GITchaque fichier que vous avez corrigé.

Astuce Git / GitHub No. 8: changer de branches production/dev/intégration à la volée

Le flux de travail d'un développeur de logiciel est rarement linéaire. Les managers / chef de projet rapportent les bugs des testeurs, et  décident de donner la priorité à tel ou tel ticket d'incident autre que celui sur lequel vous avez choisi de travailler, et vous devez travailler sur une fonctionnalité alors que vous aviez envie de travailler sur une autre.

Et voilà, avec trois fichiers commités, et un quatrième fichier dans un état cohérent mais non commité. (La commande git status vous informera de tout cela si vous n'arrivez pas à vous rappeler où vous en étiez.) Tout d'un coup, vous devez travailler sur un correctif de bug dans une nième version de production. Vous devez changer de branches très vite, mais vous ne pouvez pas. Votre répertoire de travail n'est pas cohérent (commits nno effectués) et vous avez deux heures de travail que vous ne voulez pas perdre. QUE FAIRE?

Utilisez la commande git stash. Voilà! Maintenant , vous avez tous vos changements stockés dans une branche WIP (work in progress), et vous pouvez passer à la branche de production à partir de votre propre répertoire. Lorsque vous avez terminé avec cela, revenir à l' endroit où vous étiez en appliquant la commande git stash.

Astuce Git / GitHub No. 9: Utilisez GIST pour partager des extraits de codes et snippets

Les fonctionnalités GitHub « Gist» ne sont pas une internes à Git, mais elles utilisent Git. Tous les GIST sont des dépôts Git et GitHub Gist, il est donc facile de les partager. Vous pouvez rechercher Gist pour les repositories GIST publics par sujet, par langage de programmation, par statut de forks, par état, et. Et le tour est joué. Vous pouvez également créer des GIST secrets et choisir de les partager par URL....

Une question? Posez-la ici

Aide au développement d'applications 

Astuce Git / GitHub No. 10: Explorez GitHub et trouvez des projets open sources sympas

De nombreux projets intéressants open source ont des dépôts sur GitHub. Explorez GitHub sur https://github.com/explore avec une interface de navigation sympa pour trouver certains d'entre eux, mais la plupart du temps , il est plus facile de taper quelques lettres du nom du projet dans la zone de recherche pour trouver son bonheyr.

Par exemple, tapez JQ ou back ou ang trouver trois des principaux frameworks JavaScript open source.

"ang" pour AngularJS bien sûr, j'en parle ici

Astuce Git / GitHub n ° 11: Participez et contribuez à des projets open source

Maintenant que vous visualisez des projets open source, pourquoi ne pas y participer et contribuer? Il est pas aussi difficile que vous pourriez penser, et vous apprendrez beaucoup. Par exemple, vous pouvez cloner le projet jquery projet (jQuery de base), et parcourir README.MD. Près de la racine, vous verrez:

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

Cela est possible grace à trois lignes de conduites, ou guidelines. La première des trois vous initiera assez rapidement. Tous les projets open source ne sont pas aussi clairs et aussi bien présentés, mais ils ont tous le mérite d'avoir essayé.

Comprendre la différence entre être un contributeur et un validateur. Un contributeur a signé les accords nécessaires et apporté une contribution à la disposition du projet. Un validateur est habilité à engager réellement la contribution offerte au dépôt du projet. Parce qu'il y aura un décalage entre le moment ou quelqu'un qui teste votre contribution, la modifie et la commit, et vous ne voudrez pas bugguer votre branche principale, vous devez donc faire vos changements dans une autre branche (voir astuce n ° 6) avant d'envoyer une demande de pull request .

Une question? Posez-la ici

Aide au développement d'applications 

Astuce Git / GitHub No. 12: Utiliser les éditeurs et les IDEs qui proposent « l'intégration GIT »

Si vous développez de nombreuses heures et journées pour découvrir, quand vous allez vérifier, que quelqu'un a  déja travaillé sur le même code que vous, vous êtes susceptible de devenir frustré. Vous pouvez éviter ou au moins minimiser cette frustration en utilisant un éditeur ou IDE qui intègre Git et vous indique en fait que le code que vous visionnez a de nouveaux commits que vous devez prendre en compte en tirant ce novueau code, et ce que les nouveaux commits sont censés accomplir.

Astuce Git / GitHub n ° 13: "forkez le repo"

"Forker un dépôt" signifie la création de votre propre copie du  code source présent sur le serveur, en créant ainsi comme une fourchette, qui part du manche et qui ensuite se termine en plusieurs dents. Rappelons que nous avons déja de "cloner" un repo ce qui n'est la même chose. Forker un projet c'est le rendre accessible en lecture et écriture à la communauté, pour gérer une autre propre version de code et la faire évoluer. C'est par exemple ce qu'il s'est passé avec les différentes versions de Linux, par exemple, la distribution  linux Debian a été forkée en Ubuntu. Si c'est une prise en pension publique pour laquelle nous n'avons pas engager des privilèges (voir conseil n ° 11), la meilleure façon de contribuer  et  de mettre en avant vos changements est d'abord les modifier sur votre propre "fourchette" ou fork du repo sur le serveur via le bouton de "fork" sur la projet GitHub d' origine. Ensuite , nous pouvons émettre une demande d'intégratiion, pull request aux propriétaires du manche de la fourchette afin qu'ils puissent tester et éventuellement utiliser notre dent de fourchette, c'est à dire, notre contribution. C'est déroutant au premier abord, mais ça devient plus facile avec du recul.

Astuce Git / GitHub n ° 14:  surveiller vos projets préférés

Une question? Posez-la ici

Aide au développement d'applications 

Lorsque vous forkez un projet, vous souhaitez probablement savoir ce qui se passe dans le projet original. Si oui, surveillez le repo comme ceci. Si les logs de mises à jour vous agacent, vous pouvez vous désabonner. Si vous remarquez des changements qui vous intéessent, cherchez et fusionnez les commits que vous avez vu passer.

Astuce Git / GitHub No. 15: Suivez vos amis et leurs projets

GitHub suggère que vous suiviez les inscrits sur GitHub comem sur un réseau social, « d'une manière non intrusive. » sans les harceler Vous pouvez également suivre les gens qui participent à des projets qui vous intéressent, et qui pourrait vous conduire à d' autres projets qui vous intéressent encore et ainsi de suite.... Cela peut vous ouvrir des portes incroyables et vous allez peut-être arriver comme moi à intégrer des projets fantastiques

Astuce Git / GitHub No. 16: Envoyer des pull requests

Nous avons parlé de forker un dépôt GitHub. La façon d'obtenir que votre code soit intégré au projet original (celui que vous avez forké, le manche de la fourchette) pour intégrer une partie ou toutes vos modifications est d'evoyer aux auteurs une demande de pull request.

Une question? Posez-la ici

Aide au développement d'applications 

Astuce Git / GitHub n ° 17: Créer et résoudre les problèmes

Tous les logiciels ont des bugs c'est inévitable. De nombreux projets de logiciels utilisent un système de suivi des bogues séparés, mais certains utilisent la fonctionnalité  intégrée à GitHub. Vous pouvez être utile à un projet en signalant un problème, et encore plus utile en en résolvant un!

Astuce Git / GitHub n ° 18: Ecrire les pages README d' information

On consulte la page README (exemple le projet jquery / jquery) pour connaitre l'évolution du développement. Ecrivez de bonnes pages README pour vos projets, et vous ne le regretterez pas.

README a été une convention établie dans le développement de logiciels depuis au moins les années 1960. C'est un peu comme le fichier Backlog que les développeurs Agile connaissent bien! 

Une question? Posez-la ici

Aide au développement d'applications 

Astuce Git / GitHub n ° 19: Utilisation du Markdown

Les premiers fichiers README EN MAJUSCULES étaient la base. La norme actuelle pour le formatage des fichiers README est  le Markdown, en particulier GitHub aromatise à sa sauce le Markdown. Je voyais des fichiers README au format HTML, mais la pratique semble être désuette.

Une question? Posez-la ici

Aide au développement d'applications 

Astuce / GitHub Conseil n ° 20: Convertissez vos vieux repositories CVS à Git !

De tous les conseils que j'ai énumérés, celui-ci pourrait être le plus difficile à mettre en œuvre, tant sur le plan technique et sur le plan politique. Sur le plan politique, il est difficile parce que les programmeurs sont par nature conservateurs de leurs outils (ah les vieux schnoks has been!). Cela doit être mis en place sur un plan de formation avec une bonne conduite de changement

Il est techniquement difficile de convertir de grands, anciens dépôts avec des millions de lignes de code, des dizaines de milliers de commits, et des milliers de balises parce que les processus de cette utilisation d'une tonne de mémoire. C'est peut-être le moment d'engager une bonne politique de conduite de changement dont voici les étapes!

Une question? Posez-la ici

Aide au développement d'applications