42

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.

Paul Cezanne
  • 8,629
  • 7
  • 59
  • 90
ton.yeung
  • 4,793
  • 6
  • 41
  • 72
  • Please show the command(s) you currently are using. I don't really see how a feature branch and a pull come together. Usually, a feature branch is local to the developers repository. It might be published but then it would be published to origin/features/. I don't see how a pull would merge that into master. – Daniel Hilgarth Feb 13 '13 at 16:25
  • possible duplicate of [Merge pull request to a different branch than default, in Github](http://stackoverflow.com/questions/9135913/merge-pull-request-to-a-different-branch-than-default-in-github) – CharlesB Feb 13 '13 at 16:26
  • 1
    @CharlesB That gem is for after the fact. I want to make sure my devs don't have to worry about changing the base branch whenever they issue a pull request. – ton.yeung Feb 13 '13 at 16:29

3 Answers3

38

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.

Ian Stapleton Cordasco
  • 26,944
  • 4
  • 67
  • 72
  • 9
    I'm assuming the downvote was from someone who is used to working on public repos. I'm a private shop with a private repo, so we branch from dev by default anyway. I'll try your suggestion and if it works then I will mark this as the answer. Any chance you know how to change the default branch off the top of your head? – ton.yeung Feb 13 '13 at 17:17
  • @ton.yeung I assume you figured it out, but for others, if you go to the settings tab while viewing your repository, you can change it on the first page that shows up. Cheers. – Ian Stapleton Cordasco Feb 13 '13 at 18:49
  • 2
    Making `develop` the default GitHub branch can be error prone, too, if people are used to `git clone`, `cd` into the new clone, and to then `git flow init` and hitting enter at each git-flow prompt to get the git-flow default settings. However, when the checked out branch is `develop`, git-flow will suggest that as the "Branch name for production releases", which isn't what you want for a default setup. – das-g Feb 24 '15 at 13:30
  • @das-g Exactly the situation I'm in right now with the default branch on develop. I did 'git flow init' and got stuck at the screen asking if I want 'develop' to be used for production release. I guess the solution would be to create a 'master' branch from 'develop', then do a 'git flow init' and continue as default. – RmK Oct 13 '15 at 07:53
  • 1
    @RmK If the repo on github _has_ a `master` branch, you'll probably want to create your local master branch **from that remote branch** (`git checkout -b master origin/master`) before doing `git flow init` (interactive) or `git flow init --defaults` (non-interactive). – das-g Oct 13 '15 at 09:43
  • @das-g Nope. repo on github has a single branch and that is `develop`. – RmK Oct 13 '15 at 13:14
11

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.

Josef Kufner
  • 2,851
  • 22
  • 28
5

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.

xero
  • 4,077
  • 22
  • 39
  • 3
    well that sucks. Its their system, so I guess they can work it how they want. With how popular git flow is though, i would think that they would consider supporting it, even if they don't want to use it themselves. – ton.yeung Feb 13 '13 at 16:46
  • agreed. i wish they would allow users to have more "per-repo" configuration and control. but it's still an awesome *free* service, so i can't complain too much ;D – xero Feb 13 '13 at 16:53
  • Not really free for us, since we are a commercial shop – ton.yeung Feb 13 '13 at 17:15
  • @xero, your "master" branch doesn't have to be master specifically. See my answer for how to do this otherwise. I keep master on my repositories for stable code and use `develop` and feature branches for other stuff. `develop` is also typically the default branch on my repositories – Ian Stapleton Cordasco Feb 13 '13 at 18:51
  • This question is a bit old, but the answer could use an update: they support making another branch the default: https://help.github.com/articles/setting-the-default-branch/ – Emmel Aug 23 '16 at 16:30