Set the develop branch as the default for a pull request

I want to make the pull request merge into develop from the feature branch by default.

I’m advocating the use of git flow, so when a pull request is submitted for a feature, the pull request needs to get merged into develop, and not master.

Some of the managers commented that being human, there is a possibility that the team leads could overlook that fact and merge the pull request into master by mistake, causing issues with the release later on.

We want to mitigate the risks of merge hell so this would go a long way in achieving this goal.

Edit: I’m using a fork of gitflow called hubflow(http://datasift.github.com/gitflow/). By default, when a feature branch is created git hf feature start [tik-123] the feature branch is created per spec but also gets pushed up to origin. We want this for collaboration. Once the feature is complete, the dev will go to the feature branch in github and issue a pull request. The team leads will then review the pull request and merge the feature into dev if the feature is slated for release in the sprint.

  • How can I find how many of my GitHub pull requests have been accepted?
  • How to remove commits from pull request
  • Disable merge button on GitHub till a pull request is approved
  • Why does my GitHub pull request have two commits?
  • Git Remove unwanted commits from a Pull Request
  • How to do a pull request in GitHub with only the latest commit in the master branch of my forked repository
  • How to set default fork for pull requests?
  • How to resume review process after updating pull request at GitHub?
  • 3 Solutions collect form web for “Set the develop branch as the default for a pull request”

    Alternatively make develop the default branch that everyone sees when visiting the project. The downside is that anyone who clones it will get an unstable branch by default but all pull requests will go to the develop branch by default too.

    Instead of using master and develop branches, use stable and master.

    Then it is usually good to merge them before tagging a new version, so there is none or only little diversion. I use this schema and usually stable follows master with small delay and merges are mostly fast-forward.

    To keep master branch deployable, merge feature branches when they are ready. But since you have stable branch, new features does not have to be well tested.

    The github has their own suggested workflow called github flow, by convention all pull requests default to master but you can now edit it to any branch you like.

    Git Baby is a git and github fan, let's start git clone.