Git/pull-request

Git

• Principes
• Apprendre à travailler avec Git
  1. Avant de commencer : installation et configuration de Git
  2. Création de votre dépôt local
  3. Visualiser le contenu de votre dépôt local
  4. Premiers pas
  5. Gestion des branches
  6. Synchroniser le dépôt local avec le dépôt distant
• Fonctionnalités avancées
  • Étiquetage (tags)
  • Remise (stash)
  • Recombinaison (rebase)
  • Sous-modules et Super-projets
  • Structure interne
  • Pull-request
• Recettes
  • Exclure des fichiers du dépôt
  • Écrire des messages de commit
• Environnement
  • Intégration dans les IDEs
  • Améliorer sa productivité en configurant Git
  • Git sous Linux
  • Git sous Windows
  • Forges
    • GitLab
    • GitHub
    • Bitbucket
• Git et Subversion (svn)
  • Passer de Subversion à Git
  • Travailler avec Git local et un dépôt Subversion distant
  • Participer au développement de Wikimédia (Gerrit)
• Problèmes connus
• Ressources externes

Principe

Une fois un dépôt distant cloné en local, il est facile de mettre régulièrement à jour sa version, à l'aide de la commande git pull depuis le répertoire du dépôt (via crontab par exemple).

Par contre pour envoyer ses versions développées localement sur le dépôt distant, cela nécessite une pull request (alias PR, ou merge request, MR, voire demande de tirage).

 git request-pull

Intérêt

• Déclencher une notification que le code est prêt à être fusionné, ce qui n'est pas le cas à chaque fois qu'on modifie une branche. Celle-ci a lieu généralement par email mais selon le serveur on peut configurer un hook vers du tchat ou autre.
• S’assigner la traitement de la PR.
• Joindre du texte non versionné dans Git, dans la description de la PR (ex : les cas de test). Et lister les retours de relecture / test de la branche. Ces retours peuvent même être configurés comme bloquant automatiquement le merge tant que pas résolus.
• Bloquer le merge si le résultat des pipelines CI sont en erreur.
• Voir les conflits dans la liste des PR à traiter.
• Supprimer les branches automatiquement après merge.

Mise à jour

Si la branche a été mise à jour depuis un autre client, git gère la fusion automatiquement si les fichiers modifiés sont différents. Par contre s'il y en a en commun, il faut procéder manuellement avec un rebase interactif :

 git rebase -i origin/MaBranche1

Pour éviter cela, il faut bien vérifier que la branche sur laquelle on commence à travailler est bien la dernière version, avec :

 git fetch origin/MaBranche1

• Ne pas lancer de pull après un rebase sous peine d'inclure dans sa branche locale, les commits effectués entre-temps sur la branche principale.
• Ne pas lancer un push après un reset total de la branche, car une PR sans commit sera automatiquement fermée.

Références

• https://git-scm.com/docs/git-request-pull