I’m a huge fan of git-flow; it’s branching model facilitates a release model, supporting multiple versions and branches, quite nicely. For instance, during a development phase, all commits are made to the develop branch; consequently, when it’s time to push a release into production, a release branch is created, which essentially merges everything in develop into master.
During development, however, its handy to push a snapshot of a Git repository into Heroku; which by default, receives anything from master. That is, if you aren’t careful when pushing to Heroku, you’ll end up pushing the state of master to it rather than your intended branch, which is, in this case, develop.
Accordingly, to push a branch other than master to Heroku (for instance, develop when using git-flow), you push as follows:
Note, in this case, develop is being pushed to the Heroku instance named remote_name (i.e. staging, test, etc).
Andy, I am curious about your experiences using git-flow, and how it relates to continuous integration. I recently wrote a blog post regarding this very subject and would love to get your opinion on this. I think that git-flow is an interesting tool and will definitely play with it in the near future .