introduction
Contribuer à des projets open source est une expérience enrichissante alors que vous travaillez à améliorer les logiciels pour les utilisateurs finaux comme vous. Une fois que vous avez soumis une demande d'extraction, le processus de contribution à un projet peut nécessiter un remaniement et une retouche du code avant l'acceptation, suivi d'un nettoyage général de vos branches.
Ce didacticiel vous guidera à travers certaines des étapes suivantes que vous devrez peut-être suivre après avoir soumis unpull request à un projet de logiciel open source.
Conditions préalables
Ce didacticiel vous expliquera les étapes à suivre après avoir effectué une demande d'extraction. Vous devez donc déjà installer Git et avoir déjà créé ou envisagé de créer une demande d'extraction.
Pour en savoir plus sur la contribution à des projets open source, vous pouvez lirethis introduction. Pour en savoir plus sur les demandes de tirage, vous pouvez lire «https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github[Comment créer une demande de tir sur GitHub] . "
Pendant que vous contribuez à l'open source, vous constaterez peut-être des conflits entre votre demande de branche ou d'extraction et le code en amont. Vous pouvez avoir une erreur comme celle-ci dans votre shell:
OutputCONFLICT (content): Merge conflict in your-file.py
Automatic merge failed; fix conflicts and then commit the result.Ou comme ceci sur votre demande de tir via le site Web de GitHub:
Cela peut se produire si les responsables ne répondent pas à votre demande d'extraction pendant un certain temps ou si plusieurs personnes contribuent simultanément au projet. Lorsque cela se produit et que vous souhaitez toujours fusionner votre demande d'extraction, vous devrez résoudre les conflits et redéfinir votre code.
Unrebase nous permet de déplacer les branches en modifiant le commit sur lequel elles sont basées. De cette façon, nous pouvons redéfinir notre code pour qu’il soit basé sur les commits les plus récents de la branche principale. Le changement de base doit être effectué avec précaution et vous devez vous assurer de travailler avec les bons commits et avec la bonne branche tout au long du processus. Nous allons également utiliser la commandegit reflogbelow en cas d’erreur.
Comme nous l'avons fait dans lespull request tutorial, nous allons nous déplacer dans le répertoire du code et récupérer la version amont la plus récente du code.
cd repository
git fetch upstreamUne fois que vous avez récupéré la version en amont du projet, vous pouvez nettoyer vos commentaires en écrasant ou en reformulant vos messages de validation pour les rendre plus faciles à digérer pour les responsables de projet. Si vous n'avez pas fait beaucoup de petits commits, cela peut ne pas être nécessaire.
Pour commencer ce processus, vous allez effectuer une rebase interactive. Uninteractive rebase peut être utilisé pour éditer les messages de commit précédents, combiner plusieurs commits en un seul, ou supprimer ou annuler les commits qui ne sont plus nécessaires. Pour ce faire, nous devrons être en mesure de référencer les commits que nous avons effectués, soit par leur numéro, soit par une chaîne faisant référence à la base de notre branche.
Pour connaître le nombre de commits que nous avons effectués, nous pouvons vérifier le nombre total de commits effectués dans le projet à l'aide de la commande suivante:
git logCela vous fournira une sortie qui ressemble à ceci:
Outputcommit 46f196203a16b448bf86e0473246eda1d46d1273
Author: username-2
Date: Mon Dec 14 07:32:45 2015 -0400
Commit details
commit 66e506853b0366c87f4834bb6b39d941cd034fe3
Author: username1
Date: Fri Nov 27 20:24:45 2015 -0500
Commit details Le journal montre tous les commits faits dans le référentiel du projet donné, ainsi vos commits seront mélangés avec les commits faits par d’autres. Pour les projets qui ont une longue histoire de validations par plusieurs auteurs, vous voudrez vous spécifier en tant qu'auteur dans la commande:
git log --author=your-usernameEn spécifiant ce paramètre, vous devriez pouvoir compter les commits que vous avez effectués. Si vous travaillez sur plusieurs branches, vous pouvez ajouter--branches[=<branch>] à la fin de votre commande pour limiter par branche.
Maintenant, si vous connaissez le nombre de commits que vous avez effectués sur la branche que vous souhaitez rebaser, vous pouvez simplement exécuter la commandegit rebase comme ceci:
git rebase -i HEAD~xIci,-i fait référence au rebase étant interactif, etHEAD fait référence au dernier commit de la branche maître. Lesx seront le nombre de validations que vous avez effectuées dans votre branche depuis que vous l'avez récupérée initialement.
Si, toutefois, vous ne savez pas le nombre de commits que vous avez effectués sur votre branche, vous devez déterminer quel commit est la base de votre branche, ce que vous pouvez faire en exécutant la commande suivante:
git merge-base new-branch masterCette commande renverra une longue chaîne appelée hachage de validation, qui ressemble à ceci:
Output66e506853b0366c87f4834bb6b39d341cd094fe9Nous utiliserons ce hachage de validation pour passer à la commandegit rebase:
git rebase -i 66e506853b0366c87f4834bb6b39d341cd094fe9Pour l’une des commandes ci-dessus, votre éditeur de texte de ligne de commande s’ouvrira avec un fichier contenant la liste de tous les commits de votre branche. Vous pouvez désormais choisir d’écraser ou de reformuler les commits.
Squash Commits
Lorsque nous réduisons les messages de validation, nous réduisons ou combinons plusieurs validations plus petites en une seule plus grande.
Le mot "pick" apparaît devant chaque commit, ainsi votre fichier ressemblera à celui-ci si vous avez deux commits:
GNU nano 2.0.6 Fichier:… nom d'utilisateur / référentiel / .git / rebase-merge / git-rebase-todo
pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature
# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))Maintenant, pour chaque ligne du fichier à l'exception de la première ligne, vous devez remplacer le mot "pick" par le mot "squash" pour combiner les commits:
GNU nano 2.0.6 Fichier:… nom d'utilisateur / référentiel / .git / rebase-merge / git-rebase-todo
pick a1f29a6 Adding a new feature
squash 79c0e80 Here is another new featureÀ ce stade, vous pouvez enregistrer et fermer le fichier, ce qui ouvrira un nouveau fichier qui combine tous les messages de validation de toutes les validations. Vous pouvez reformuler le message de validation à votre guise, puis enregistrer et fermer le fichier.
Vous recevrez des commentaires une fois que vous avez fermé le fichier:
OutputSuccessfully rebased and updated refs/heads/new-branch.Vous avez maintenant combiné tous les commits en un en les écrasant ensemble.
Reformuler les commits
La reformulation des messages de validation est idéale lorsque vous remarquez une faute de frappe ou que vous réalisez que vous n'utilisiez pas de langage parallèle pour chacune de vos validations.
Une fois que vous avez effectué le rebase interactif comme décrit ci-dessus avec la commandegit rebase -i, vous aurez un fichier ouvert qui ressemble à ceci:
GNU nano 2.0.6 Fichier:… nom d'utilisateur / référentiel / .git / rebase-merge / git-rebase-todo
pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature
# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))Maintenant, pour chacun des commits que vous souhaitez reformuler, remplacez le mot «pick» par «reword»:
GNU nano 2.0.6 Fichier:… nom d'utilisateur / référentiel / .git / rebase-merge / git-rebase-todo
pick a1f29a6 Adding a new feature
reword 79c0e80 Adding a second new feature
# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))Une fois que vous avez sauvegardé et fermé le fichier, un nouveau fichier texte apparaît dans votre éditeur de terminal. Il indique le libellé modifié du message de validation. Si vous souhaitez modifier le fichier à nouveau, vous pouvez le faire avant de sauvegarder et de fermer le fichier. Cela peut vous assurer que vos messages de commit sont utiles et uniformes.
Complétez la base
Une fois que vous êtes satisfait du nombre de commits que vous effectuez et des messages de validation pertinents, vous devez compléter la base de la rebase de votre branche, en plus de la dernière version du code en amont du projet. Pour ce faire, vous devez exécuter cette commande à partir du répertoire de votre référentiel:
git rebase upstream/masterÀ ce stade, Git commencera à rejouer vos validations sur la dernière version de master. Si vous rencontrez des conflits alors que cela se produit, Git se met en pause pour vous demander de résoudre les conflits avant de continuer.
Une fois les conflits résolus, vous allez exécuter:
git rebase --continueCette commande indiquera à Git qu'il peut maintenant continuer à rejouer vos commits.
Si vous avez précédemment combiné des validations en utilisant la commandesquash, vous n'aurez besoin de résoudre les conflits qu'une seule fois.
Mettre à jour la demande d'extraction avec Force-Push
Une fois que vous avez effectué un rebase, l'historique de votre branche change et vous ne pouvez plus utiliser la commandegit push car le chemin direct a été modifié.
Nous devrons à la place utiliser l'indicateur--force ou-f pour forcer les changements, informant Git que vous êtes pleinement conscient de ce que vous faites.
Assurons-nous d'abord que notrepush.default estsimple, qui est la valeur par défaut dans Git 2.0+, en le configurant:
git config --global push.default simpleÀ ce stade, nous devrions nous assurer que nous sommes sur la bonne branche en consultant la branche sur laquelle nous travaillons:
git checkout new-branchOutputAlready on 'new-branch'
. . .Maintenant, nous pouvons effectuer le push-force:
git push -fVous devriez maintenant recevoir des commentaires sur vos mises à jour avec le message indiquant qu'il s'agissait d'unforced update. Votre demande d'extraction est maintenant mise à jour.
Récupération des commits perdus
Si, à un moment donné, vous avez lancé un engagement que vous vouliez vraiment intégrer au projet plus vaste, vous devriez pouvoir utiliser Git pour restaurer les engagements que vous avez peut-être jetés par accident.
Nous allons utiliser la commandegit reflog pour trouver nos commits manquants, puis créer une nouvelle branche à partir de ce commit.
Reflog est l'abréviation dereference logs qui enregistre la dernière mise à jour des extrémités des branches et autres références dans le référentiel local.
À partir du répertoire local du référentiel de code dans lequel nous travaillons, exécutez la commande suivante:
git reflogUne fois que vous exécutez cette commande, vous recevrez une sortie qui ressemble à ceci:
Output46f1962 HEAD@{0}: checkout: moving from branch-1 to new-branch
9370d03 HEAD@{1}: commit: code cleanups
a1f29a6 HEAD@{2}: commit: brand new feature
38f2fc2 HEAD@{3}: commit: remove testing methods
. . .Vos messages de validation vous permettront de savoir lequel des validations est celui que vous avez laissé derrière, et la chaîne correspondante sera avant les informationsHEAD@{x} sur le côté gauche de la fenêtre de votre terminal.
Maintenant, vous pouvez prendre ces informations et créer une nouvelle branche à partir du commit correspondant:
git checkout -b new-new-branch a1f29a6Dans l'exemple ci-dessus, nous avons créé une nouvelle branche à partir du troisième commit affiché ci-dessus, celui qui a déployé une «toute nouvelle fonctionnalité», représentée par la chaînea1f29a6.
En fonction de ce que vous devez faire à partir d'ici, vous pouvez suivre les étapes de configuration de votre branche dansthis tutorial on pull requests, ou revenir auxtop of the current tutorial pour travailler à rebaser la nouvelle branche.
[.note] #Note: Si vous avez récemment exécuté la commandegit gc pour nettoyer les fichiers inutiles et optimiser le référentiel local, vous ne pourrez peut-être pas restaurer les commits perdus.
#
À quoi s'attendre dans une révision de code
Lorsque vous soumettez une demande d'extraction, vous dialoguez avec un projet plus important. Soumettre une demande de tirage, c'est inviter les autres à parler de votre travail, tout comme vous-même discutez et engagez-vous dans un projet plus important. Pour que vous ayez une conversation réussie, il est important que vous puissiez communiquerwhy que vous faites la demande d'extraction via vos messages de validation, il est donc préférable d'être aussi précis et clair que possible.
L’examen de la demande de tirage peut être long et détaillé, selon le projet. Il est préférable de considérer le processus comme une expérience d'apprentissage et un moyen efficace d'améliorer votre code et de rendre la demande d'extraction plus efficace et plus conforme aux besoins du projet de logiciel. L’examen devrait vous permettre d’apporter les modifications vous-même en suivant les conseils et les recommandations des responsables.
La demande d'extraction tiendra un journal des notes des réviseurs et des mises à jour et discussions que vous avez ensemble. Vous devrez peut-être effectuer plusieurs validations supplémentaires tout au long de ce processus avant que la demande d'extraction ne soit acceptée. Ceci est tout à fait normal et vous offre une bonne opportunité de travailler sur la révision en équipe.
Votre demande d'extraction continuera d'être maintenue via Git et sera mise à jour automatiquement tout au long du processus, à condition que vous ajoutiez des commits à la même branche et que vous les déplaciez vers votre branche.
Bien que vous diffusiez votre code dans le monde entier pour examen par vos pairs, vous ne devriez jamais avoir l'impression que la révision devient personnelle, alors assurez-vous de lire les fichiersCONTRIBUTION.md ou les codes de conduite pertinents. Il est important de vous assurer que vos commits sont alignés sur les directives spécifiées par le projet, mais si vous commencez à vous sentir mal à l'aise, le projet sur lequel vous travaillez peut ne pas mériter votre contribution. Il existe de nombreux espaces d'accueil dans la communauté open-source et, même si vous pouvez vous attendre à ce que votre code soit examiné avec un œil critique, tous les commentaires que vous recevrez doivent être professionnels et courtois.
Tirer demande d'acceptation et supprimer votre branche
Toutes nos félicitations! Si votre demande d'extraction a été acceptée, vous avez contribué avec succès à un projet de logiciel open-source!
À ce stade, vous devrez extraire les modifications que vous avez apportées dans votre fourche via votre référentiel local. C'est ce que vous avez déjà fait lorsque vous êtes passé par le processus verssync your fork. Vous pouvez le faire avec les commandes suivantes dans la fenêtre de votre terminal:
git checkout master
git pull --rebase upstream master
git push -f origin masterMaintenant, vous devez nettoyer vos branches locales et distantes en supprimant la branche que vous avez créée aux deux endroits, car elles ne sont plus nécessaires. Commençons par supprimer la branche locale:
git branch -d new-branchL'indicateur-d ajouté à la commandegit branch supprimera la branche que vous passez à la commande. Dans l'exemple ci-dessus, il est appelénew-branch.
Ensuite, nous allons supprimer la branche distante:
git push origin --delete new-branchAvec les branches supprimées, vous avez nettoyé le référentiel et vos modifications sont désormais stockées dans le référentiel principal. N'oubliez pas que, même si les modifications apportées via votre demande d'extraction font désormais partie du référentiel principal, elles peuvent ne pas être disponibles pour l'utilisateur final moyen qui télécharge des versions publiques. En règle générale, les développeurs de logiciels regrouperont plusieurs nouvelles fonctionnalités et correctifs dans une seule version publique.
Conclusion
Ce tutoriel vous a guidé à travers certaines des étapes suivantes que vous devrez peut-être effectuer après avoir soumis unpull request à un référentiel de logiciels open-source.
Contribuer à des projets open source - et devenir un développeur open source actif - est souvent une expérience enrichissante. En contribuant régulièrement aux logiciels que vous utilisez fréquemment, vous vous assurez qu'ils sont précieux et utiles pour votre communauté d'utilisateurs.