Tutoriel simple pour faire votre premier PR (Pull Request)

Eh bien, je pense que celui-ci sera un tutoriel assez court et, espérons-le, didactique;). Je vais mettre à votre disposition un petit référentiel sur mon github afin que vous puissiez envoyer vos PR et en même temps pour que vous puissiez vous entraîner à faire toutes les étapes que je vais laisser ci-dessous. Voici le lien pour faire votre test PR:

https://github.com/CodeLabora/TuPrimerPR

Eh bien, listons rapidement les étapes nécessaires pour envoyer un PR:

1. Fourche
2. Cloner
3. Remote
4. Branche
5. changements
6. Ajouter
7. S’ENGAGER
8. Push
9. PR

Je les mets en anglais pour qu'ils trouvent leurs options respectives sur la ligne de commande git.

Fourche

Un fork est votre propre version d'un référentiel Github. Cela vous permet de cloner le travail d'un autre projet et de l'avoir dans votre compte afin de pouvoir changer des choses sans craindre de perdre vos modifications. Pour faire une fourche, il suffit d'aller sur la page et de cliquer sur le bouton Fourchette qui se trouve dans la partie supérieure droite.

Une fois le fork terminé, vous verrez que le référentiel apparaît dans votre compte.

Cloner

Maintenant que nous avons un référentiel, nous allons le cloner dans notre équipe. (Je suppose que les utilisateurs de Linux me suivent, mais pour les utilisateurs d'autres systèmes, il existe également des versions de git que vous pouvez télécharger sur leur page officielle.

Et avec notre terminal, nous faisons ce qui suit.

Avec cela, nous aurons un nouveau dossier appelé TuPrimerPR dans lequel sera notre projet Github. Nous entrons dans le dossier avec la commande «cd TuPrimerPR» et nous verrons qu'à l'intérieur se trouvent les fichiers qui sont dans notre fork.

(Notez que le nombre de fichiers peut varier en fonction de ce qu'ils trouvent dans mon référentiel lors de leur fourchette)

Remote

Il s'agit d'une étape facultative, mais elle évite de nombreux problèmes lorsque l'on travaille en continu sur un projet. Fork par défaut crée une copie exacte du référentiel, mais au moment exact de la création. Cela signifie que si le projet continue d'avancer, votre référentiel va prendre du retard au fil des jours ou des heures. "Git remote" nous permet de spécifier un autre point de téléchargement (le projet d'origine) et ainsi de pouvoir mettre à jour notre projet à chaque fois que nous voyons que le projet parent est en cours de mise à jour.

Pour trouver votre projet parent, il vous suffit d'utiliser le lien qui se trouve juste en dessous du nom de votre référentiel. (Vérifiez la deuxième image de la section Fork). Nous allons ajouter ces informations ci-dessous:

C'est le projet original (nous l'appellerons en amont pour suivre de nombreux projets).

Comme vous pouvez le voir, j'ai ajouté la télécommande avec »git remote add »

Avec cela, nous pourrons mettre à jour le projet si nécessaire, mais nous ne l'utiliserons pas maintenant car ce n'est pas nécessaire. (J'expliquerai cela plus tard, ou dans un autre post, selon le besoin)

Branche

Les branches (ou branches) vous permettent de créer des sections de code que vous pouvez travailler dans un environnement isolé. Cela signifie que ce que vous faites dans une branche n'affecte pas nécessairement le code d'origine jusqu'à ce qu'un »git merge« soit utilisé. C'est aussi une fonctionnalité supplémentaire que Github vous permet, chaque fois que vous créez une branche, Github génère automatiquement la source de la Pull Request si nécessaire.

Maintenant que nous sommes dans notre branche spéciale, nous pouvons travailler sur notre contribution.

changements

Je vais ajouter quelques fichiers pour que vous puissiez voir comment c'est fait.

"Touch" nous permet de créer un fichier vierge (s'il n'existe pas). avec cela, nous pouvons passer à notre prochaine étape.

Ajouter

»Git add» nous permet d'ajouter des fichiers à notre commit (j'expliquerai plus tard). Pour voir quels fichiers vous pouvez ajouter, vous pouvez utiliser la commande »git status»

Avec cela, nous avons tout prêt pour notre engagement

S’ENGAGER

Les validations sont des marques (ou jalons) dans le temps. ils définissent un état pour tous les fichiers du projet et cumulent les modifications nécessaires pour passer du début du projet à l'état actuel. Cela semble un peu complexe, mais c'est assez simple, rappelez-vous simplement que ce sont les escaliers de votre projet. Nous écrivons «git commit» et nous aurons une fenêtre pour écrire notre message de commit.

Et lors de la fin et de l'enregistrement du texte, nous verrons quelque chose comme:

Où un résumé de ce que fait le commit est affiché.

Push

Avec push, nous téléchargeons sur notre compte Github tous les commits que nous avons sur l'ordinateur qui ne sont pas dans notre référentiel sur Internet. Cela permettra à Github de générer automatiquement le nouveau PR.

Notez que nous utilisons le nom de notre succursale et qu'elle nous demande notre nom d'utilisateur et notre mot de passe. À la fin, cela nous montre que la branche myImprovement a été créée dans notre compte Github. Voyons ce que nous avons réalisé dans le navigateur. 😉

PR

Comme vous pouvez le voir, une nouvelle ligne a été créée qui dit "Compare & Pull request". Cette fonctionnalité Github nous permet de créer le PR de manière simple, nous allons cliquer pour voir ce qui se passe.

Github est assez intelligent. Comme vous pouvez le voir, des parties du commit sont ajoutées au formulaire pour soumission. Il suffit de cliquer sur le bouton et le tour est joué 🙂 Simple.

Extra

C'est dans les coulisses des projets, le PR apparaît et le manager décide d'accepter ou non, ou d'écrire plus de messages. Dans mon cas, je l'accepterai instantanément.

Une fois la fusion terminée, ils pourront voir le journal de validation du projet et y voir leur nom.

Mais maintenant, nous avons un problème. Ce commit n'apparaît pas dans de notre référentiel, uniquement dans le projet. Vous souvenez-vous de notre passage lointain? C'est maintenant que ça paie 🙂

Nous retournons à notre branche principale et procédons comme suit:

Avec cela, nous avons téléchargé toutes les informations du projet original à notre équipe. Comme vous pouvez le voir, notre commit y apparaît. Nous allons maintenant enregistrer tout ce travail dans notre référentiel Github pour pouvoir supprimer la branche qui a la contribution qu'ils ont déjà ajoutée au projet.

Maintenant que nous avons notre référentiel Github mis à jour, nous allons supprimer notre branche, mais d'abord nous nous assurons qu'elle se trouve dans notre branche principale (master)

Comme vous pouvez le voir, j'ai eu une petite erreur, car j'étais dans ma branche myImprovement lorsque je voulais supprimer. Ceci est résolu en retournant à la branche principale.

Conclusion

Fait 🙂 aussi simple que cela. Maintenant que vous maîtrisez les sombres secrets de Github pour l'envoi de relations publiques, j'ai hâte de voir vos contributions sur divers projets. Et si vous le souhaitez, vous pouvez laisser votre premier PR dans mon référentiel 😉 pour la mémoire.

Je n'ai pas touché aux mille et un avantages Git (YEUX, pas Github) et comme on peut s'y attendre de la part des développeurs liés à la communauté du noyau, Git est un outil extrêmement puissant, avec des centaines de fonctionnalités.

Afin d'avoir une meilleure idée de ce qu'il fait et de toute la puissance de Git, je le recommande vivement livre. Je suis sûr que cela vous aidera beaucoup à améliorer votre gestion de git.

Salutations et j'espère que cela vous aidera 😉