[dgomez1092]

I don't understand the benefit to this as opposed to the CLI?

[ikawe]

For me, when something is merged into master, that means that it is immediately destined for deployment.

so instead of

    git co master
    git merge --no-ff feature/my_feature
    git push github
    git push heroku

Just becomes

    git co master
    git merge --no-ff feature/my_feature
    git push github

Just saving a step. And also saving the confusion that happens when something is in master and not deployed because someone got distracted.

Also, you could deploy to heroku as the result of merging a pull request through the github web-ui (if you're into that kind of thing).

[pc86]

Disclaimer: I don't use the git CLI and I've deployed maybe 3 apps to Heroku, all just playing around with it.

Isn't this so that someone can just keep Github up to date and they don't need to use the CLI and do `heroku push` or whatever every time there is an update?

We use Microsoft Azure for some public sites, and there is both Github and BitBucket integration where you can automatically deploy updates to certain branches (e.g. `master` or `develop`) to the site.

[anderspetersson]

You could use something like "git push heroku master" before, but with this you dont need to setup a separate remote when using github+heroku, you can simply just push to github, that means the code that you see on github is the same as the one running on heroku, that wasn't always the case before.

[ajsharma]

I use atmos/heaven for a similar functionality. It's nice because it ensures that the master branch on Github has gone through out automated tests and that whoever is deploying is deploying exactly the code from Github and not some strange variant locally.