We're using BitBucket to host some private repos for clients lately. This is a great approach for small teams, you can get private repos for FREE, but your team size is limited to 6 team members I think.
So setting up remotes on your website server is easy, you add the SSH remote to be able to do pull requests from the repo:
git remote add firstname.lastname@example.org:your-account/your-repo-name.git
All fine and good, but what *IF* you want to actually PUSH some changes from this branch? Trying the following push request:
git push origin develop
Gives you an access denied error:
conq: repository access denied. access via a deployment key is read-only. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
Instead of using the SSH remote, add a second remote that uses HTTP. Instead of relying on an SSH key (which is not present when using the SSH remote as pull only), the HTTP remote will prompt the user for a user/pass authentication.
Add a second remote:
git remote add origin-push https://email@example.com/your-username/your-repo-name.git
Now you can use the second origin to do the push command:
git push origin-push develop
Pushes made will require a valid user/pass to complete. This also means you don't have to set up a SSH identity for the server. If you really want to be safe, you can just remove the origin you just created when you are finished using it.
git remote rm origin-you-want-to-remove
This gives you the option to do a one-time push to your remote without ever leaving the ssh terminal.
Let me know what you think!
*IF* CAVEAT - I know it's bad form to just be pushing changes from a live server, but if you've done some live-site triage you want to get the exact fixes into the repo. This gives you a chance to do this. My goal is practical repeatable success, and this approach can provide that. I consider it an EXPEDIENT EXCEPTION, rather than a general practice!