Probably not a good idea - you'll get into trouble if the site is down because of code issues. But not really that bad either.

You can't actually have the real copy of the repository used as the work-space for Phorge Repository: Phorge might make changes to the local file system, and you don't want that.
Phorge will also generally prefer bare repos, rather then regular clones.

You can have Phorge "host" the repository, and then have the real install be a clone of that repository served by Phorge. You'll need to bootstrap by cloning from somewhere else, and then update the remote uris in the installed repo.
As long as you remember to fetch everything before starting the upgrade flow, this works well enough.

At we.phorge.it, the current flow we use is something like this:
The hosted repositories are mirrored to Github (We don't have any secret code, so that's easy).
The clones in the installed version have several remotes, including both GH and Phorge. We rarely use these remotes.

Instead, when I want to update, I do this:

• Login to server as avivey
• I have a "staging" repository in ~/avivey/staging/<repo>
• I use a combination of push and pull from my home machine to this staging repo (Often for RC commits, that aren't actually pushed anywhere else. You probably don't need a "staging" space otherwise).
• In the production install, I have a remote called avivey-staging, that's looking at ~/avivey/staging/<repo>.
• I do sudo git fetch avivey-staging (in each repo)
• When I'm ready to do the actual change, I keep a backup (sudo git branch -f last-known-good) and update the local space (git reset --hard avivey-staging:new-target)
• continue with the rest of the upgrade process.