deploy on heroku

Creating a Heroku Remote

Git remotes are references to remote repositories. You can have any number of these, but for now we’ll focus on just the remote to Heroku. The heroku create command creates a new application on Heroku - along with a git remote that must be used to receive your application source.

$ heroku create --stack cedar
Creating falling-wind-1624... done, stack is cedar
http://falling-wind-1624.herokuapp.com/ | [email protected]:falling-wind-1624.git
Git remote heroku added

You can verify the remote in your git configuration as well:

$ git remote -v
heroku     [email protected]:falling-wind-1624.git (fetch)
heroku     [email protected]:falling-wind-1624.git (push)

You can also take an existing Git repo and add a remote using the git URL provided when you created your app. You may need to do this to associate a Git repo with an existing application.

If you don’t have the git URL for your app on-screen anymore, you can always see it again by typing: heroku info --app appname.

The git URL for a Heroku app is always in the format [email protected]:appname.git. Once you get used to this format, you may find it easier to type than cut-and-paste each time.

$ git remote add heroku [email protected]:appname.git

The remote is named heroku in this example, but you can name the remote anything you want. You will probably find it easier to follow the examples if you stick to this naming convention.

There is one special remote name: origin, which is the default for pushes. Using origin as the remote name will allow you to type just git push instead of git push heroku, but we recommend using an explicitly named remote.

Deploying Code

Your Heroku app starts with a blank repository - it has no branches and no code. So the first time you deploy, you’ll need to specify a remote branch to push to:

$ git push heroku master
updating 'refs/heads/master'
...

This will push your code to the heroku remote, created earlier. Branches pushed to Heroku other than master will be ignored by this command. If you’re working out of another branch locally, you can either merge to master before pushing, or specify that you want to push your local branch to a remote master. To push a branch other than master, use this syntax:

$ git push heroku yourbranch:master

Multiple Remotes and Environments

The same techniques used to deploy to production can be used to deploy a development branch of your application to a staging application on Heroku, as described in Managing Multiple Environments for an App.

Using Subversion Or Other Revision Control Systems

What if you’re already using Subversion or another revision control system to track your source code? Although we believe that Git is one of the best choices available for revision control, you don’t need to stop using your current revision control system. Git can be purely a deployment mechanism, existing side-by-side with your other tool.

You can learn much more about .gitignore in our article on the topic.

For example, if you are using Subversion, initialize your Git repo as described above. Then, add a .gitignore file to tell Git to ignore your Subversion directories.

$ git init
$ echo .svn > .gitignore
$ git add .
$ git commit -m "using git for heroku deployment"

Now tell Subversion to ignore Git:

$ svn propset svn:ignore .git .
property 'svn:ignore' set on '.'
$ svn commit -m "ignoring git folder (git is used for heroku deployment)"

The -f (force flag) is recommended in order to avoid conflicts with other developers’ pushes. Since you are not using Git for your revision control, but as a transport only, using the force flag is a reasonable practice.

Each time you wish to deploy to Heroku:

$ git add .
$ git commit -m "commit for deploy to heroku"
...

$ git push -f heroku




some times ,may be you get errors info like this :
  !  No such app as fierce-fog-63 fatal: The remote end hung up unexpectedly
 
you can fix it like this:
git remote rm heroku heroku create