Comment limiter qui peut fusionner le code sur une demande de traction dans bitbucket?

J'ai une petite équipe de développeurs qui utilisent bitbucket que notre dépôt git.

Je veux savoir comment faire pour limiter les personnes qui peuvent fusionner le code sur un pull request dans bitbucket? ET/OU de force, à moins d'une approbation avant la fusion peut être fait. Fondamentalement, je suis à la recherche de la force d'une révision du code.

Aujourd'hui le créateur d'une pull-request (et tous les autres) ne peut qu'approuver, mais aussi de fusionner le code qui peut être un problème pour la qualité. Merci à l'avance.

Mise à jour:

Bitbucket permet maintenant de contrôler pousser des autorisations, de la direction générale de la suppression, et l'histoire de la ré-écriture. La gestion complète des instructions sont ici: https://confluence.atlassian.com/bitbucket/branch-management-385912271.html

Il n'est toujours pas un moyen de forcer un nombre minimum de approbations cependant.

source d'informationauteur Shawn | 2013-08-04

  1. 12

    Je veux savoir comment faire pour limiter les personnes qui peuvent fusionner le code sur un pull request dans bitbucket? ET/OU de force, à moins d'une approbation avant la fusion peut être fait. Fondamentalement, je suis à la recherche de la force d'une révision du code.

    Cette fonctionnalité n'est pas disponible dans Bitbucket pour l'instant, mais Atlassian est derrière un pare-feu version de Git d'hébergement.

    Stash vous permet de:

    • limite qui peut changer les branches

    • imposer un nombre minimum de approbations nécessaires avant la fusion des pull requests (il peut faire quelque chose de similaire pour le Bambou construit - à-dire le code doit compiler avant de pouvoir être fusionnées)

    • réinitialiser les approbations si une demande d'extraction des changements

    C'est une curieuse asymétrie dans Atlassian propres produits.

  2. 0

    Réponse de attlassian:

    Marie Anthony [Atlassian Rédacteur Technique]

    Salut,

    Donc, un dépôt peut avoir des succursales. Dans ce référentiel, vous ne pouvez pas
    définir des autorisations sur une branche qui sont différents à partir du référentiel.
    Vous pouvez définir des autorisations sur le référentiel qui permettrait aux développeurs
    la fourche à la fourchette le référentiel et d'émettre des pull requests contre elle. Pour
    configurer ceci:

    Create a group on your account and call it  "developers".
Give the group read permissions.
Add all the developers to that group.
Edit the groups on the repository and add developers.

    Espère que cette aide.

    Marie

    Ici, il est: https://confluence.atlassian.com/display/BITBUCKET/Work+with+pull+requests?focusedCommentId=321851850#comment-321851850

    En d'autres mots, vous pouvez faire votre dev fourche du projet et la question de tirer les demandes de leurs fourche. Dans votre projet , vous pouvez définir le projet d'interdire le public de la fourche. Je suppose qu'ils vont fourche du projet et il sera caché. Cela dit, ils seront en mesure de délivrer des pull request et modifier leur propre référentiel. Il semble tout à fait akward, mais il devrait fonctionner.

    Je n'ai pas le sentiment qu'il ya une bonne façon de gérer les autorisations sur github/bitbucket et ainsi de suite.

    modifier

    Pas vraiment une solution pour le faire valoir, mais encore tout à fait valable. Depuis l'approbation de pull-request est tout à fait facultatif. Ne veut pas dire que vous êtes foutu et en fait, si j'étais vous. Je ne voudrais pas essayer d'appliquer un système. La réalité est que la révision du code est importante. Pull request facilite l'examen des ensembles de commits.

    J'ai travaillé plusieurs mois d'être le seul dans mon équipe pour créer et/ou approuver les pull requests. L'équipe dans laquelle j'ai travaillé a décidé que les pull requests était un gaspillage de temps et je suppose qu'aucun d'entre eux n'a l'examen du code jusqu'à ce que je l'ai quitté. La dernière chose que j'ai entendu, c'est que mon coéquipier est actuellement refactoring mon code car il n'a aucune idée de comment cela fonctionne.

    Ce que j'essaie de dire, c'est que la révision du code ne devrait pas être appliquée et votre équipe devez le voir comme une chose très importante que de le faire. Chaque membre de votre équipe doit travailler ensemble et à la révision du code des uns et des autres sur leur propre. En faisant la revue de code, ils ont le droit de refuser le code qu'ils se sentent est "laid" ou devraient être conçus d'une manière différente. Chaque membre de l'obtenir pour rester à jour sur ce que les autres devs travaillent et ne peuvent pas avoir beaucoup de problème de commutation sur tout le monde du travail en cas de maladie, de départ ou la mort!

    Appliquer le processus dans le système peut être bon à partir d'un gestionnaire de point de vue. Mais je crois que le fait d'avoir l'approbation option n'est pas mal non plus. Et puis, le gestionnaire de l'emploi sera de vérifier la fusion de pull request pour le pull request avec 1 ou moins approuvé personne. Vérifier qui a fusionné les pull request et qui l'a approuvée. Trouver quelqu'un pour passer en revue le code de toute façon.

    Sur l'autre main, si une demande d'extraction est suspendu autour pour toujours et personne n'est à l'examen. C'est le dev de la tâche de demander à un pote de le revoir.