Single branch development is easy. But this strategy’s easiness blows up once you release code to the general public. If you need to hot-fix an instance of deployed code, while in the midst of a development cycle, single branch development gets in your way by requiring you think. On the other hand, having more than one branch at least allows you to jump back in time via an alternate branch to perform a patch, while not disturbing an unfinished developmental branch. And you can do this without having to think much.

Consequently, if you have multiple Git branches (such as those managed via git-flow) you can map those branches to different Heroku environments quite easily. First, you’ll want to appropriately name your remote Heroku environments; for instance, you can name the remote repositories prod, test, staging, etc.

You can add a remote Git repository like so:

1

git remote add <name> git@heroku.com:<heroku_app_name>.git

Where heroku_app_name is the name you gave your app or the one automatically created by Heroku via the heroku create command.

With different Heroku environments, you can easily map each one to a Git branch. For instance, a production environment can map to the master branch and a test environment can map to a branch called release. If you have a development environment, that can map to a branch dubbed develop (note, these branch names correlate nicely with git-flow’s defaults).

To deploy the release branch to your Heroku test environment, you can issue this command:

1

git push test release:master

If you deploy often (i.e. push a lot!) and you can’t seem to remember the release:master portion, you can create a remote alias like so:

1

git config remote.test.push release:master

Thus, deployments to the test environment are as simple as:

1

git push test

Heroku’s deployment model, which leverages Git, couldn’t be any simpler; what’s more, setting up a release pipeline with multiple environments mapped to different Git branches is just as easy. Dig it?