Skip to content

Who should merge a PR? #1

Open
Open

Description

@hkdobrev
  • A developer pushes his code, opens a PR.
  • His peers review it and approve the changes.
  • Everybody has push access so anyone could merge it.
  • Merging the PR to master would immediately deploy (if the tests pass).

Who should merge the PR and therefore approve not only the changes, but the deployment at this moment as well?

Side notes:

  • We do not use feature flags (yet).
  • Sometimes we need to deploy a feature only after certain event/time despite the feature being complete.
  • We don't want master (for deployments), develop (to base new work) and feature branches, just a simple structure of master and feature branches.

Activity

  1. hkdobrev commented on Dec 14, 2013

    @hkdobrev
    Author

    Right now we are using the following workflow:

    • A developer opens a PR.
    • A colleague approves the changes.
    • The person who has opened the PR should merge when he sees fit, because he is the one who should know best when this should land on production.

    However if a feature is ready and reviewed, but should not be deployed for quite some time we are left with an open PR which just hangs there.

    Do you think tagging could help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions