web-dev-qa-db-fra.com

Comment envoyer une demande de pull sur Git

Nous avons récemment migré vers Git depuis SVN. Nous avons configuré un référentiel nu sur une machine de notre réseau LAN et cloné sur d'autres machines. Maintenant, quand quelqu'un fait les modifications et s'engage, nous voulons qu'il envoie la demande de tirage au référentiel nu (en le disant ou en envoyant un e-mail ou de toute autre manière) après cela, on passera par les modifications et le tirera sur le référentiel nu (comme cela fonctionne sur GitHub).

Avons-nous besoin d'installer une interface ou il y a des commandes dans Git lui-même?

gitgit-svnpull-request
56
jimy

Git (le logiciel) et GitHub (le service Web) ont tous deux un concept appelé "pull request", et malheureusement ce n'est pas exactement la même chose.

Native Git

La commande native Git request-pull A une très courte page de manuel avec la description d'une phrase suivante:

Récapitule les modifications entre deux validations sur la sortie standard et inclut l'URL donnée dans le résumé généré.

Il s'agit d'une commande de bas niveau qui génère un bref résumé des modifications qui convient à la publication sur une liste de diffusion. Les autres utilisateurs peuvent utiliser l'URL publiée dans cette "demande d'extraction" pour extraire manuellement les modifications dans leur propre référentiel.

Demandes d'extraction GitHub

Lorsque vous utilisez service Web GitHub , un Pull Request est un outil de collaboration interactif complet. Une demande d'extraction GitHub a:

  • une description plus détaillée des modifications que les résumés de validation individuels
  • notifications envoyées automatiquement aux utilisateurs qui ont choisi de regarder le projet
  • une interface d'examen en ligne où les autres peuvent commenter les modifications proposées
  • commentaires de discussion pour l'enregistrement de conversations sur les validations
  • gestion centralisée des demandes de pull afin qu'elles ne se perdent pas

Il convient de noter que Linus a sa propre opinion sur l'utilité relative de ces deux fonctionnalités.

Conclusion

Les deux fonctionnalités de "pull request" décrites ci-dessus sont similaires dans leur esprit mais complètement différentes dans leur mise en œuvre. En particulier, la commande git request-pull Ne peut pas être utilisée pour créer une nouvelle requête Pull sur GitHub. Vous avez plusieurs choix si vous souhaitez prendre en charge la fonctionnalité de type "pull request":

  • Utilisez GitHub. Cela implique certainement le moindre effort, mais si votre projet n'est pas public, vous devrez payer GitHub pour héberger un référentiel privé. Certaines personnes pourraient ne pas être à l'aise avec ce choix.
  • Utilisez Gerrit . Gerrit est un programme serveur open-source que vous pouvez télécharger qui offre de nombreuses fonctionnalités similaires à celles disponibles dans GitHub. Il est particulièrement bien adapté aux revues collaboratives de code.
  • Utilisez git request-pull Et une liste de diffusion. L'utilisation de cette méthode nécessite beaucoup plus de discipline de la part de vos ingénieurs, car il est facile d'errer ou de mal gérer les messages de la liste de diffusion. Il n'y a pas de responsabilité centrale associée à cette méthode.
77
Greg Hewgill

Le terme "pull request" n'est pas pas un terme spécifique à github.

Il existe une commande git request-pull, vous pouvez en savoir plus ici: http://linux.die.net/man/1/git-request-pull

Pour des explications plus approfondies et vous faire économiser un peu de recherche sur Google:

Ce n'est pas une nouvelle fonctionnalité BTW.

EDIT: Cette réponse alternative a été faite avant la réécriture de la réponse initialement acceptée par @Greg Hewgill. Je l'ai posté parce que c'est la réponse que je cherchais, et je pense que cela correspondait à la question qui demandait de faire des pull pulls pour les utilisateurs qui n'utilisent pas necesarilly en utilisant github (Oui, tout le monde n'utilisant pas git utilise github, du moins pas tout le temps). Maintenant que la réponse d'origine a été réécrite, rendant cette différence explicite, je vais laisser cette réponse telle que je l'avais initialement publiée pour mémoire.

57
Jens

La "façon git" de faire cela serait que tous les développeurs aient leur propre référentiel nu public (accès en lecture à tous, accès en écriture pour le développeur lui-même) sur le serveur comme leur "origine". Et si vous aimez un "tronc" supplémentaire (ou "stable" ou comme vous voulez l'appeler), un repo nu auquel certains ou tous les développeurs ont accès en écriture. Les développeurs mettent en miroir leur dépôt sur leur dépôt public et se détachent des autres développeurs. De cette façon, vous n'avez pas à vous inquiéter si vous envoyez quelque chose à votre référentiel public qui ne fonctionne pas encore. (Les développeurs peuvent simplement tirer de vous vers une branche de test et voir si cela fonctionne.) Lorsque vous avez une branche canonique stable, vous pouvez la pousser vers le dépôt "trunk".

10
Stein G. Strindhaug