git remote rep ubuntu linode

Private Remote Git Repositories Using Ubuntu On Linode

In working on my latest project, I’ve made a bunch of development changes. I’ve switched over to Ruby on Rails (which has been great so far), started using Git in my workflow, and have automated my app deployment with Capistrano. There have been some learning curves, especially with the lack of coherent documentation for most of the stuff, so it has been frustrating at times. I made sure to take detailed notes though as I worked through the process of learning all of this stuff, and I’m planning on posting a few guides here on how to do some of the stuff that I now use daily. So hopefully that’s something that will help anyone interested in adding some new stuff to their current workflows.

Bring In The Git

I’m not going to go into too many details as to why Git is great or the technical explanation of how the hell it works because quite frankly I don’t really know. I do know enough about it to know that it’s better to use than not use and if you’re serious about coding, you should use it. Main reasons why?

  1. Versioning is a good thing. Versioning + remote backups = great thing
  2. You should never modify your production code base. Always branch out from it, code on the branch, test, merge back, deploy. Don’t break working code.

So basically, Git allows you to break shit without risking your entire project (and sanity).

On To The Guide

Anyone expecting a long, thorough guide, will be disappointed. But that’s a good thing in this case, because setting up your own remote repos on your own Linode VPS is stupid easy. There isn’t that much documentation out there for some reason on this topic (I guess all the cool kids are on Github), so that’s why I’m writing this now. So here we go…

1) Install git on your server. SSH into your Linode, and (assuming you’re on Ubuntu) run “apt-get install git-core”

2) On your local machine, install Git. Depends on your OS, there are guides everywhere for this.

3) Back on the server, navigate to and create a folder where you’ll house the remote repo. This should be a non-public folder. I chose /srv/git (my apps are stored in /srv/www/[app-folder]). Assuming you’re using /srv/git, the workflow would be:

[cc]mkdir /srv/git

cd /srv/git

mkdir [project-name]

cd [project-name] [/cc]

4) In your new project folder, run the command [cci]git init –bare[/cci]. This will create an empty repository for your project.

5) Back on your local machine, you need to add the remote repo as a remote target to your Git setup. To do that, run:

[cc]git remote add origin ssh://[username]@[domain/ip/hostname]/srv/git/[project-name] [/cc]

What that did was add the remote target of [cci]origin[/cci]. I have no idea why everyone calls their remote repos origin…if someone has an answer, I’ll mail you a cookie.

6) Now, work locally on your project. When you’re ready to commit and push to your server, the workflow looks like:

[cc]git add .

git commit -m “my commit”

git push origin [branch-name][/cc]

So if you were working on your master branch, you would use [cci]git push origin master[/cci]. That command would calculate all your repo deltas and push only your changes to your server. WIN.

Moving Forward

Once you’ve nailed that workflow, there’s some awesome advanced stuff you can do. Namely, deploying a Rails app with Capistrano and Git. It’s sexy when it works, but confusing as hell to figure out. I’ll post a few more guides that will hopefully help you get started with that stuff as well.


  1. Well said. You have exactly a point with what you are saying here. I agree when you said that Versioning can be also a good thing. And i guess it is always necessary that you should always branch out from it, code on the branch, test, merge back, deploy.

  2. Unless I read wrong (happens here and there) – don’t forget to init the local repo.

    Mac OSX here. Thx for tutorial, just getting my Git dialed in. Much appreciated.

    1. yep, you’re exactly right marc, I will edit this post to fix that. I am actually a Github convert now so I don’t even practice what I preach anymore, but glad that this was helpful at least!

  3. The name “origin” is the convention name for the default remote, also it is hardcoded in git, so you can just do a “git push”, without specifying the remote and get the same result as “git push origin”

Leave a Reply

Your email address will not be published. Required fields are marked *

Optimization WordPress Plugins & Solutions by W3 EDGE