Essayez le cherry-pick de PR GitHub

• Cela fait 4 mois que nous avons commencé à utiliser un mono-repository en interne
• Nous appliquons également en parallèle le trunk-based development, un mot-clé qui accompagne souvent les mono-repositories
• Conformément à la stratégie de trunk-based development, nous utilisons un flow où l’on commit sur la branche main, puis on effectue des cherry-picks vers la branche de release
• En nous basant sur le contenu du blog technique de LinkedIn, nous avons mis en place une GitHub Action, mais elle ne résout pas automatiquement les CONFLICT. Lorsqu’un CONFLICT survient, l’utilisateur doit exécuter lui-même la commande git cherry-pick en local
• J’ai donc créé moi-même un plugin gh pour faciliter cette commande cherry-pick

Utilisation

gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]  

• L’option -merge permet de choisir s’il faut faire le cherry-pick du merge commit de la PR ou des commits d’origine de la PR
  • Si elle n’est pas précisée, ou si l’option -merge=auto est utilisée, la stratégie de merge utilisée par la PR est automatiquement inspectée puis appliquée
• L’option -push permet de lancer automatiquement un push vers le remote si le cherry-pick réussit

Retour d’expérience

• En développant un programme qui interagit en continu avec des processus et des états externes, j’ai créé un repository de test distinct afin de constituer un jeu de données de test
  • Mon expérience passée de contribution aux projets libgit2 et refined-github m’a été utile
• Divers apprentissages pour améliorer l’expérience CLI
  • Le travail d’étude mené pour essayer de recréer docker-cli en solo m’a aidé
• Créer un programme CLI demande plus d’efforts qu’on ne l’imagine
  • gérer de nombreuses valeurs d’état dans une structure en pipeline
  • fournir à l’utilisateur une interface d’entrée intuitive
  • proposer une validation des entrées le plus tôt possible
  • remettre le système de l’utilisateur dans son état d’origine, etc.
  • Je pensais pouvoir le faire en une journée environ, mais cela m’a finalement pris près de 5 jours (même si le développement pour améliorer le workflow GitHub Actions avançait en parallèle, cela a tout de même demandé bien plus de temps que prévu)

[qncnxnlrla]

Bonjour~ Comment gérez-vous les cas où un commit mergé dans la branche main (trunk) doit être revert ?

• Si on fait un revert sur la branche main, est-ce que cela sera aussi cherry-pick vers la branche release ?
• Vous ajoutez un commit de correction sans utiliser revert ?

J’imagine qu’avec beaucoup de commits accumulés, le cherry-pick peut devenir difficile s’il y a des conflits ; je serais curieux de savoir si vous avez déjà eu à gérer ce type de cas !

[a1eng0]

Bonjour, merci pour votre réponse !

Comment procédez-vous lorsqu’un commit fusionné dans la branche main(trunk) doit être revert ?

Nous spécifions un cherry-pick dans la PR de revert ouverte sur la branche main. Comme tout l’historique des cherry-picks reste visible dans le lien de la PR d’origine, il n’y a pas de difficulté particulière pour le suivi. Nous n’effectuons pas non plus de vérification mécanique séparée haha.

Lorsqu’il y a beaucoup de commits accumulés et qu’un conflit survient, il peut être difficile de faire un cherry-pick

En pratique, avec le trunk-based development, chaque PR est de petite taille, donc les conflits ne surviennent pas souvent. Si un conflit se produit malgré tout, il faut écrire le code manuellement. Nous faisons des release très fréquemment afin de déprécier rapidement le support des versions trop anciennes et d’éviter que l’état du code ne diverge trop fortement.

[lamanus]

Je ne comprends pas vraiment pourquoi cette stratégie est nécessaire...

[a1eng0]

Je pense que lire le contenu présenté dans release-from-trunk pourra vous aider à mieux comprendre, haha.