Est-il préférable de démarrer une requête Pull ou d'effectuer une validation de fusion locale sur le maître?
J'utilise GitHub depuis un certain temps maintenant et j'ai l'habitude de pousser mes branches de fonctionnalités, puis de lancer une requête Pull que j'ai moi-même fusionnée. J'ai trouvé que cela m'a aidé à garder une trace de l'endroit où j'ai fusionné les succursales.
Mais récemment, j'ai lu de plus en plus sur le fonctionnement de Git et j'ai réalisé que je pouvais utiliser les merge-commits pour faire référence à la fusion de branches.
Alors, que dois-je faire lors de la fusion d'une branche de fonctionnalité en maître:
Effectuez une fusion-validation sur le maître, puis poussez-la en amont [~ # ~] ou [~ # ~] Poussez la branche locale et lancer une Pull Request?
J'ai lu Présentation des demandes de tirage pour une équipe de 2 personnes - fusionner mes propres demandes? et Quel est le flux de travail avec 2 personnes sur un projet et Dois-je ouvrir tirer des requêtes d'une branche sur le référentiel officiel ou ma fourchette? mais aucun d'entre eux ne semble répondre à ce que je recherche.
mécanisme de fusion-git:
En utilisant git merge feature tandis que sur master fusionne la branche feature à master et produit un merge-commit (si la branche ne peut pas être avancée rapidement) dans l'historique git. Pour forcer un merge-commit étant fait, utilisez le --no-ff option avec merge.
Mécanisme de demande d'extraction de fusion:
Lorsque nous démarrons une Pull Request sur GitHub, cela crée un GitHub Issue où les gens peuvent parler et discuter des commits dans le PR avant de le fusionner. Lorsqu'un PR est fusionné sur GitHub, il fait exactement la même chose que git merge feature.
Que dois-je faire?
Donc, en ce qui concerne l'histoire, il n'y a pas de différence entre les deux.
Et en ce qui concerne la contribution, vos contributeurs n'auront rien de différent pour les deux situations. Ce sont les mêmes (moins le joli petit chat).
Meilleures pratiques:
Et je n'ai pas pu trouver de meilleures pratiques, mais la logique dit que les RP ne sont pas très utiles s'il n'y a qu'une seule personne sur le référentiel.
@lxrec et @amon m'ont aidé à parvenir à cette conclusion.
Comme Ashhar l'a dit, techniquement et historiquement, il n'y a pas de différence. Pour les projets avec une petite équipe, je préfère fusionner directement au lieu de l'étape supplémentaire de création d'un PR. Cependant, lorsqu'une fonctionnalité doit être revue/commentée ou lorsqu'il s'agit d'un WIP et que plus d'une personne y travaillera, j'ai tendance à ouvrir un PR et à ajouter une liste de tâches à la description du PR.
Notez que git merge peut utiliser l'avance rapide s'il n'y a aucun changement à master, vous pouvez donc utiliser git merge --no-ff. J'ai tendance à ne pas le faire.
Donc, en résumé, n'utilisez les RP que lorsque vous avez besoin de discussion. Sinon, fusionnez directement.