We have local feature branches, a github origin branch and Heroku staging and production remote branches.
As local features become ready for review by a larger audience we'd like to push them to staging:
$ git push staging local-branch-name:master
Fetching repository, done.
To [email protected]:app-staging.git
! [rejected] local-branch-name -> master (non-fast-forward)
error: failed to push some refs to '[email protected]:app-staging.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Part of me wants to --force the issue but git push -f to a remote is taboo. I could pull in the changes as the "hint" says but given that the branches we push into staging are often short lived and may have little to do with each other this seems like it would be unnecessary and confusing.
What is the proper procedure for sharing a staging server on Heroku?
You're essentially using git on your staging server as a deployment mechanism, not for version control. You already have your real remote on github, so I don't see the harm in force pushing to your staging server as long as you never pull changes from it.
Force pushing is typically a bad idea for two reasons.
You can lose commits. If you force push to a remote that is ahead of your branch, those commits ahead of yours will be lost.
You can mangle other developers' repositories. If you force push to a remote branch that another developer has already pulled, their branch will be out of sync with the remote and it could be difficult to recover.
However, in this case you are only pushing to the repository. You will never lose commits because the upstream will never be ahead of any particular branch. Also, it is never pulled by other developers. For those reasons, it is ok to force push in this case.