Permettez-moi d'être plus clair. Les réponses et discussions précédentes sont spécieuses et ne pointent pas vers la vérité.
pull request et git pull sur Github ne sont pas complètement sans rapport, mais la relation la plus proche avec celle-ci est une autre commande git request-pull.
Parlons d’abord de l’explication conceptuelle. Peut-être que la plupart des gens (y compris le sujet) comprendront la pull request comme ceci :
Je soumets une pull request pour intégrer mes modifications en amont (généralement la source de votre fork)
Dans ce cas, il me semble que la demande push devrait être la plus appropriée, car cette action est entièrement de mon initiative !
Cependant, cette compréhension ignore une prémisse : Avez-vous la permission de pousser vers l'amont ? Autrement dit, peut-on écrire directement en amont ?
Ceci est divisé en deux situations (correspondant à deux workflows basés sur Git) :
Si vous avez la permission, alors vous n'avez pas besoin de fork & pull request Puisque l'auteur vous a donné la permission, vous pouvez simplement le cloner et l'exploiter comme votre propre dépôt.
Aucune autorisation - puisqu'il n'y a pas d'autorisation, comment puis-je dire demande push ?
En fin de compte, ce malentendu provient d'un manque de compréhension complète du fonctionnement du workflow de pull request. La description correcte de l'action pull request devrait ressembler à ceci :
J'initie une requête (pour Github, c'est une requête HTTP qui appelle l'API correspondante, puis Github l'exécute sur le backend git request-pull, voir ci-dessous pour plus de détails), cette requête (requête en requête HTTP ) est une demande adressée à (demande dans la pull request) l'auteur en amont pour extraire (pull in pull request) les modifications de mon fork.
C'est la bonne compréhension.
Enfin, parlons git request-pull. Lorsque vous effectuez une requête pull request, la sous-commande git request-pull est en fait exécutée en coulisses. La signature (principale) de cette sous-commande est :
bash$ git request-pull <start> <url> [<end>]
Cette commande génère un résumé des modifications (dans les commits) et les URL utilisées pour les récupérer. Le résumé est affiché sur la sortie standard en texte brut au format fixe, que vous pouvez rediriger et écrire du code pour un traitement ultérieur. C'est ainsi que Github analyse chaque pull request, afin que vous puissiez voir le commit, l'heure, l'auteur et d'autres informations correspondants.
Si l'auteur en amont choisit d'accepter la demande après avoir reçu la pull request, Github appellera git pull pour extraire le code de l'adresse spécifiée (incluse dans les informations générées par git request-pull). L'auteur en amont a naturellement l'autorisation d'écrire dans le dépôt en amont, afin qu'un processus complet puisse être réalisé.
Il est recommandé de lire le manuel officiel de Git, en particulier ce chapitre : Distributed Git - Contribuer au projet, je vous garantis que vous en bénéficierez beaucoup après l'avoir lu.
C'est une bibliothèque publique, n'est-ce pas ? Vous apportez vos modifications à cette bibliothèque, puis l'auteur de cette bibliothèque peut voir votre demande et décider de vous fusionner dans sa bibliothèque d'origine.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Permettez-moi d'être plus clair. Les réponses et discussions précédentes sont spécieuses et ne pointent pas vers la vérité.
pull request et
git pullsur Github ne sont pas complètement sans rapport, mais la relation la plus proche avec celle-ci est une autre commandegit request-pull.Parlons d’abord de l’explication conceptuelle. Peut-être que la plupart des gens (y compris le sujet) comprendront la pull request comme ceci :
Dans ce cas, il me semble que la demande push devrait être la plus appropriée, car cette action est entièrement de mon initiative !
Cependant, cette compréhension ignore une prémisse : Avez-vous la permission de pousser vers l'amont ? Autrement dit, peut-on écrire directement en amont ?
Ceci est divisé en deux situations (correspondant à deux workflows basés sur Git) :
En fin de compte, ce malentendu provient d'un manque de compréhension complète du fonctionnement du workflow de pull request. La description correcte de l'action pull request devrait ressembler à ceci :
C'est la bonne compréhension.
Enfin, parlons
git request-pull. Lorsque vous effectuez une requête pull request, la sous-commandegit request-pullest en fait exécutée en coulisses. La signature (principale) de cette sous-commande est :Cette commande génère un résumé des modifications (dans les commits) et les URL utilisées pour les récupérer. Le résumé est affiché sur la sortie standard en texte brut au format fixe, que vous pouvez rediriger et écrire du code pour un traitement ultérieur. C'est ainsi que Github analyse chaque pull request, afin que vous puissiez voir le commit, l'heure, l'auteur et d'autres informations correspondants.
Si l'auteur en amont choisit d'accepter la demande après avoir reçu la pull request, Github appellera
git pullpour extraire le code de l'adresse spécifiée (incluse dans les informations générées pargit request-pull). L'auteur en amont a naturellement l'autorisation d'écrire dans le dépôt en amont, afin qu'un processus complet puisse être réalisé.Il est recommandé de lire le manuel officiel de Git, en particulier ce chapitre : Distributed Git - Contribuer au projet, je vous garantis que vous en bénéficierez beaucoup après l'avoir lu.
C'est une bibliothèque publique, n'est-ce pas ? Vous apportez vos modifications à cette bibliothèque, puis l'auteur de cette bibliothèque peut voir votre demande et décider de vous fusionner dans sa bibliothèque d'origine.