Renommer une branche lors d'une demande d'extraction

101

Sur Github, vous pouvez effectuer des pull requests pour ajouter des fonctionnalités à un projet. Les contributions doivent être sur une branche qui, si la demande est acceptée, sera fusionnée dans la branche maître (ou une branche analogue) du projet.

Maintenant, j'ai soumis une pull request sur Github et mes contributions sont sur une branche appelée patch-1. Je peux modifier le nom de la branche localement en

git branch -m patch-1 newname

et en principe, je peux également le renommer sur mon repo fourchu sur Github en suivant les instructions trouvées dans cette réponse . Cela se fait en pratique en supprimant l'ancienne branche, patch-1dans mon cas, et en la repoussant avec un nom différent newname.

Est-il autorisé à renommer la branche patch-1sur mon dépôt forké sur Github quand il s'agit d'une pull request? Ou cela pose des problèmes sur la gestion des pull request?

Existe-t-il un moyen de renommer une branche sur un référentiel forké sur Github lorsque cette branche est une pull request?

git github pull-request

— Michele
source

117

"Renommer" une branche distante dans git, comme indiqué par le lien que vous avez fourni, consiste en fait simplement à supprimer une branche, suivie de la poussée d'une nouvelle branche avec le même hachage de validation mais un nouveau nom. Si vous avez une demande d'extraction ouverte pour la branche patch-1, lorsque vous supprimez cette branche, la demande d'extraction sera fermée.

Donc, non, vous ne pouvez pas renommer la branche avec une demande d'extraction ouverte sans supprimer la branche et supprimer la demande d'extraction. Cependant, rien ne vous empêche de faire cela, de pousser une nouvelle branche avec un nouveau nom et de créer une nouvelle pull request.

— arbylee
source

186

une des raisons de ne pas le faire est de perdre la discussion sur le PR existant.

— Johnny Everson

6

Je ne comprends pas pourquoi une restriction aussi stricte sur le changement de nom de la branche source sur PR. Le même comportement ennuyeux existe dans bitbucket. Une autre approche consisterait à éditer le PR et à changer la branche source en une autre branche. On pourrait dire "si vous changez de branche source, alors c'est quand même un nouveau PR". Techniquement, oui, mais aussi rien n'empêche le développeur de configurer en amont d'une branche complètement différente et de faire ensuite un git push -f. Le PR est mis à jour avec un nouveau code entier et est toujours le «même» PR.

— L. Holanda

31

Réponse courte:

Non

Approche alternative:

Ouvrir un nouveau PR avec une nouvelle succursale (renommée)
Fermez l'ancien PR en référençant le nouveau (par exemple, fermé en faveur de #new_pr_id)
Modifier la description du nouveau PR (par exemple, remplace #old_pr_id)
(facultatif) Faire un commentaire sur une discussion pertinente sur l'ancien PR

Remarque:

Le nom d'une branche distante (constituant un PR) devait changer, car le système de construction avait besoin du nom de la branche qui se termine par l'ID du ticket. Cependant, le PR a été ouvert avant la création officielle des billets (à partir des spécifications) et avait contenu de précieuses discussions. L'approche décrite était le seul moyen de faire fonctionner le système de construction et de ne pas perdre d'informations (bien qu'il y ait eu une étape supplémentaire pour le suivre).

— Slobodan Ilic
source

9

Étant donné que les branches sont généralement supprimées après la fusion, je pense qu'il vaut mieux "tolérer" que le nom soit inexact pendant un certain temps plutôt que d'ajouter la surcharge d'un nouveau PR qui se réfère à l'ancien PR dans le but de suivre la discussion historique.

— Neo