`Github` 上的 `pull request` 与 `Git` 的 `pull` 有关系么？

Question

之前用 SAE 的时候学了点 svn，后来发现还是 Git 先进，再后来就把注册许久不用的 Github 账号拿出来捣鼓，结果对 pull request 很迷惑。

Update:
[上一秒] pull 不是拉么？怎么地想也感觉是 push request 才对。
[下一秒] 哦！对作者来说是 pull 。。。

那就是两者一点都不搭边咯，一个是 CLI 的命令，一个是 Github 上概念性的东西。

Answer 1

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) :

1. 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.
2. 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.

Answer 2

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.