Article original : How to make your first Pull Request on GitHub
De nombreux tutoriels existent sur ce sujet, mais ils compliquent trop les choses en supposant qu'il faut contribuer du code à un projet.
Et si vous deviez simplement modifier un fichier, peut-être le README du projet pour corriger une faute de frappe ?
Vous n'avez pas besoin de savoir coder ou utiliser Git pour cela. Mais une fois que vous commencez à faire des Pull Requests, vous pouvez faire beaucoup plus de choses et collaborer sur des projets avec d'autres personnes ! Et peut-être que cela vous poussera à contribuer du code plus tard.
Je suppose que vous avez déjà un compte GitHub (gratuit). Si ce n'est pas le cas, rendez-vous sur github.com et créez-en un.
Laissez-moi vous montrer le processus.
Je suis allé sur cette page https://web.dev/prefers-color-scheme/ et j'ai trouvé une possible faute de frappe. Cette ligne manque un point à la fin.
Je ne suis pas un puriste de la grammaire, c'est juste pour l'exemple ?
Je sais que ce site est hébergé sur GitHub, et que cet article exact est hébergé ici : https://github.com/GoogleChrome/web.dev/tree/master/src/site/content/en/blog/prefers-color-scheme
J'ouvre le fichier index.md https://github.com/GoogleChrome/web.dev/blob/master/src/site/content/en/blog/prefers-color-scheme/index.md directement sur GitHub et j'appuie sur l'icône de crayon dans la barre d'outils du fichier. En survolant, il est écrit "Fork this project and edit the file".
Cela ouvre une vue d'éditeur avec cette information :
Vous modifiez un fichier dans un projet pour lequel vous n'avez pas les droits d'écriture. Soumettre une modification à ce fichier l'écrira dans une nouvelle branche de votre fork flaviocopes/web.dev, afin que vous puissiez envoyer une pull request.
Je peux ajouter ce point, puis dans le formulaire en bas, j'explique les modifications que j'ai apportées :
J'ai appuyé sur le bouton "Propose File Change" et une vue de comparaison est apparue.
Là, je peux passer en revue les modifications que j'ai apportées, pour m'assurer que tout est correct, et enfin je peux cliquer sur le bouton "Create Pull Request". Actuellement, les modifications ont été apportées à votre fork du projet, qui a été créé automatiquement par GitHub lorsque vous avez cliqué sur l'icône de crayon.
En haut de cette vue, vous pouvez voir que je suis sur le point de soumettre une PR au projet GoogleChrome/web.dev depuis mon fork flaviocopes/web.dev, de ma branche patch-2 vers leur branche master.
Appuyer sur le bouton "Create Pull Request" affiche un autre formulaire où je peux écrire une description détaillée pour la Pull Request.
Les Pull Requests peuvent contenir de nombreuses modifications différentes, donc en théorie, vous pourriez avoir beaucoup de fichiers modifiés dans la même PR, c'est pourquoi vous pouvez ajouter un résumé.
Ce dépôt a un modèle pour le texte de la PR, pour aider l'équipe à le gérer. Notre PR est très simple, donc je supprime le modèle et je colle simplement le contenu du message de commit précédent.
Remarquez l'indice à droite ? Ils me disent que le projet a un fichier CONTRIBUTING.md, qui explique comment contribuer et les directives. Plutôt cool.
Il semble que nous devions signer un CLA (Contributor License Agreement) pour finaliser notre PR. J'ai déjà signé un Google CLA dans le passé, donc cette étape est claire pour moi, mais vous devrez peut-être le faire. La plupart des projets n'en ont pas vraiment besoin.
J'ai cliqué sur "Create pull request" et la PR est maintenant envoyée !
Maintenant, c'est aux mainteneurs du projet de prendre le relais et de l'accepter, vous devez simplement attendre un email vous informant qu'elle a été fusionnée, ou tout commentaire d'autres personnes.
[... quelques heures se sont écoulées...]
J'ai reçu un email en retour, la PR a été rejetée car ce point était en fait à la bonne place ! (Je ne le savais pas).
Mais voici une chose que je voulais ajouter : ne soyez pas en colère ou contrarié si une PR que vous soumettez n'est pas acceptée. Les mainteneurs du projet y travaillent depuis des mois ou des années et ils savent mieux que vous ce qui est bon pour lui.
De plus, surtout avec le code, les avis peuvent être très différents et une PR que vous pensez géniale peut ne pas être la bienvenue.
Il est également préférable de demander avant de travailler sur une PR substantielle, pour voir si c'est quelque chose dont le projet a vraiment besoin.
Les corrections de bugs sont des débuts faciles.
Je suis Flavio. J'écris des tutoriels pour les développeurs sur flaviocopes.com