Fermeture manuelle de la demande de tirage de bitbucket
Ma question
Je fais des choses comme ça:
git clone
git checkout -b new_feature
< work and commit >
git rebase master
< work and commit >
< finish working >
git rebase master
git Push Origin new_feature
< I create pull request via bitbucket's web interface >
Quelqu'un qui examine les modifications fait:
git pull
git checkout master
git merge --squash new_feature
git Push Origin master
J'espérais que cela fermerait la demande de tirage comme acceptée, mais ce n'est pas le cas.
Quelques informations de base
J'ai lu beaucoup de documentation de bitbucket "travailler avec des requêtes d'extraction" mais ce n'est toujours pas clair pour moi.
Je peux voir que tous mes commits de la branche new_feature ont été appliqués à la branche master (via git merge --squash) et je peux voir quels fichiers ont été modifiés, mais maintenant, lorsque je clique sur "merge" sur l'interface de requête pull-bit, j'ai un autre commit en maître qui est fusionné et cela ne change aucun fichier (toutes les modifications ont déjà été appliquées par le précédent git merge --squash) mais amène simplement tous ces historiques de commits dans le maître, ce qui n’est pas ce que je voulais.
Via: https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests
Extraction manuelle des demandes sur votre système local
Il est parfois judicieux d'utiliser un flux de travail dans lequel vous testez un ensemble de modifications Sur votre système local avant d'accepter une demande d'extraction. Vous Pouvez le faire avec n'importe quelle demande d'extraction. Le flux de travail typique est le suivant: Recevez une demande d'extraction dans Bitbucket. Mettez à jour votre référentiel local avec Le jeu de modifications entrant. Examinez et/ou testez le jeu de modifications. Si vous Le jeu de modifications est correct, vous le fusionnez dans votre référentiel local. Vous Devrez peut-être résoudre certains conflits. Ensuite, vous repoussez le référentiel local Vers Bitbucket. De retour sur Bitbucket, la demande d'extraction est marquée comme acceptée dans l'onglet Demandes d'extraction. Si vous n'aimez pas la demande de modification , Vous ignorez les modifications localement et rejetez la demande d'extraction Sur Bitbucket. Des idées?
METTRE À JOUR
Au 31 janvier 2017 une fonctionnalité a été mise en œuvre pour remédier à l'impossibilité de fermer les PR manuellement.
S'il vous plaît se référer à (et upvote!) la réponse de @BenAmos pour plus de détails.
Réponse originale
(conservé à des fins historiques)
Rien ne te manque. Bitbucket ne ferme pas automatiquement votre demande d'extraction lorsqu'elle a été fusionnée.
Vous devez manuellement fermer la demande d'extraction vous-même en sélectionnant l'option "Refuser".
Si je comprends bien, il existe deux façons de fermer une demande d'extraction Bitbucket en tant que "Fusionné".
- Cliquez sur le bouton "Fusionner". Bitbucket fusionnera votre branche de fonctionnalité Dans la branche de destination. (Les versions les plus récentes de Bitbucket vous permettent de choisir entre les stratégies --no-ff et --squash. Les versions plus anciennes utilisent implicitement --no-ff.)
- Utilisez les commandes de la console git (ou une autre interface) pour fusionner votre branche Dans votre branche de destination, puis transmettez les deux à l’origine.
La première option est certainement la plus simple et la plus simple, mais elle ne fonctionne pas bien avec certains flux de travail de développement.
La clé pour que la deuxième option fonctionne est que votre branche de fonctionnalité doit être sur votre branche de destination. Bitbucket recherche périodiquement les demandes d'extraction qui ont été fusionnées manuellement et, lorsqu'elles sont détectées, marque automatiquement ces demandes d'extraction comme étant fusionnées. Remarque: Atlassian n'annonce pas ce comportement. Je n'ai trouvé aucun document officiel à l'appui de cette affirmation, mais au moins une autre personne a vu que cela fonctionnait .
En fonction du flux de travail que vous avez décrit, je suppose que la personne qui a examiné et mis en avant vos modifications a un historique de git qui ressemble à ceci:
* ddddddd (Origin/master, master) new feature, squashed
| * ccccccc (Origin/new_feature, new_feature) new feature part C
| * bbbbbbb new feature part B
| * aaaaaaa new feature part A
|/
o
Dans ce cas, le moyen le plus simple de demander à Bitbucket de fermer automatiquement la demande d'extraction serait:
git branch --force new_feature ddddddd
git Push --force Origin new_feature
Cela fonctionne également pour les branches de fonctionnalités qui ont été rebasées.
AVERTISSEMENT! Gardez ces faits à l'esprit:
- Tous les flux de travail ne permettent pas de telles pressions.
- Bitbucket met automatiquement à jour les commits indiqués par une demande d'extraction À chaque changement de branche. En fonction de l'ordre dans lequel Vous poussez vos branches, cela peut donner une liste de validation vide. (Plus de détails ci-dessous.)
- Lorsqu'une demande d'extraction est fermée, tout historique de validation et toute information diff Sont gelés.
Lorsque vous transmettez votre branche de destination à Origin avant de pousser votre branche, Bitbucket commence par rechercher les validations sur la nouvelle branche qui ne sont pas sur la branche de destination. Étant donné que la nouvelle branche est un ancêtre de la branche de destination, le résultat est un ensemble vide. Par conséquent, Bitbucket supprime toutes les validations de l'onglet Commits de la demande d'extraction, qui se lit désormais comme suit: "Il n'y a aucune modification." Ensuite, comme la branche de la fonctionnalité figure dans l'historique de la branche de destination, Bitbucket ferme la demande d'extraction en gelant l'onglet des validations vide de la manière suivante:
Curieusement, le diff reste intact dans ce cas.
Si aucune des options de fusion ci-dessus ne vous convient, les seules options restantes sont les suivantes:
- Refuser la demande d'extraction.
- Pensez à changer votre flux de travail pour quelque chose que Bitbucket supporte plus facilement .
- Float une requête de fonctionnalité avec Bitbucket/Atlassian.
Voir aussi la documentation sur git-branch et git-Push .
BitBucket Server 4.5.1 a modifié la manière dont les fusions distantes sont classées dans la demande d'extraction (c'est-à-dire refusées ou fusionnées).
La réponse de @BenAmos ci-dessus fonctionne bien, mais si vous envoyez le commit de fusion à la branche de destination AVANT de forcer sur la branche de fonctionnalité, BitBucket fermera automatiquement la demande d'extraction et la classera comme "refusée".
Toutefois, si vous forcez plutôt Push sur la branche de fonctionnalité AVANT de pousser le commit de fusion sur la branche de destination, BitBucket fermera automatiquement la demande d'extraction et la classera comme "fusionnée".
De Atlassian: "Une demande d'extraction sera désormais refusée après un Push si: il n'y a pas de validations sur la branche depuis la branche qui ne sont pas également sur la branche vers ET si la branche n'a pas été mise à jour dans la même Push "
Référence: https://jira.atlassian.com/browse/BSERV-4219?src=confmacro&_ga=1.138319284.547646488.1457297841
Je suppose que bitbucket ne reconnaît pas vos relations publiques comme étant fusionnées, car git merge --squash génère complètement new commit. Dans notre société, nous avons également essayé les branches de fonctionnalité git merge --squash lorsqu’elles ont été fusionnées dans la branche principale, mais nous l’avons abandonné car les demandes de tirage fusionnées restaient en suspens. Nous devions ensuite les "refuser" ou supprimer les branches de fonctionnalité distantes associées.
Ce que nous sommes en train de faire, c’est de réduire toutes les commissions de branche d’entité en une seule opération et de forcer le transfert vers une branche d’entité distante. Après cela, la personne responsable de la fusion dans le maître doit simplement cliquer sur "Fusionner" sur la page de demande d'extraction du bitbucket. Le PR est marqué "Fusionné" et toutes les modifications introduites dans la branche de fonctionnalité sont écrasées dans un commit précis. .