Private Git Hosting: Total Control for Distributed Teams
If I have to resolve one more svn merge conflict on a Friday night, I might just pull the plug on the rack. Centralized version control was fine when we were all sitting in the same LAN in Fornebu, but now that we have developers in Kyiv and designers in Bergen, Subversion (SVN) is becoming a massive bottleneck.
The solution isn't just "switching to Git." It's about hosting it correctly. Sure, GitHub is making waves, but do you really want your proprietary code sitting on a public cloud in the US? Not to mention the latency. Every `git push` shouldn't give you time to brew coffee.
Here is the battle-tested setup we are rolling out for high-performance, private version control using CoolVDS Linux instances. This setup keeps your data under Norwegian jurisdiction (Datatilsynet compliant) and offers the raw speed your team needs.
Why Latency Kills Productivity
We ran a `traceroute` yesterday. From our Kyiv office to a US-based host, we are looking at 180-220ms. That makes terminal interaction feel like wading through mud.
By hosting on a VPS in Norway (specifically on CoolVDS's backbone), we cut that down to 40ms from Ukraine and <10ms from Oslo. When you are dealing with large binary assets or massive repo histories, that difference is the line between "flow state" and frustration.
Pro Tip: Don't settle for standard SATA drives for your repo server. Git is I/O intensive during garbage collection (`git gc`). We strictly use RAID 10 SAS storage configurations on CoolVDS to ensure disk queues never choke your commits.
The Stack: CentOS 5.3 + SSH
We are using CentOS 5.3 for this. It's rock-solid. We aren't interested in the bleeding edge; we want stability. We will use standard SSH for authentication because it is secure, already installed, and easily managed via `authorized_keys`.
Step 1: Secure the VDS
Before you install anything, lock the door. On a fresh CoolVDS instance, update your system and configure `iptables`.
yum update -y
# Allow SSH, HTTP, and Loopback only
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP
Step 2: Install Git Core
CentOS base repositories can be a bit behind. Ensure you have the EPEL repository enabled or compile from source if you need the absolute latest 1.6.x features. For now, `yum` is sufficient.
yum install git
Step 3: Create the Git User
Never run your repositories as root. Create a dedicated user for version control. This isolates your code from the rest of the system.
adduser git
passwd git # Set a strong password
Step 4: Set Up SSH Keys
Password authentication is a security risk and a hassle for automation. Gather the `id_rsa.pub` keys from your developers. On the server:
su - git
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
Paste your developers' public keys into that `authorized_keys` file, one per line.
Step 5: Initialize the Bare Repository
A "bare" repository contains no working files, just the version history. This is what you push to. Let's create a repo for `project-alpha`.
cd /home/git
mkdir project-alpha.git
cd project-alpha.git
git --bare init
Client Side: The First Push
Back on your local machine (your workstation in Oslo or Kyiv), you can now add this remote. Since we are using CoolVDS, you'll use the IP or hostname provided in your welcome email.
cd my-project
git init
git add .
git commit -m "Initial commit"
# The magic happens here
git remote add origin git@your-coolvds-ip:project-alpha.git
git push origin master
If you set up the keys correctly, it will push immediately. No passwords, no waiting.
Why Not Just Use Shared Hosting?
I've seen people try to host Git on standard shared hosting accounts via WebDAV. Don't do it.
| Feature | Shared Hosting | CoolVDS (Virtual Dedicated) |
|---|---|---|
| RAM Access | Shared/Choked | Guaranteed/Dedicated |
| Protocol | Slow HTTP/WebDAV | Fast SSH |
| Data Privacy | Risky | Strict Norwegian Standards |
Shared hosting creates "noisy neighbor" issues. If another site on the server gets hit with traffic, your `git pull` times out. On a dedicated resource platform like CoolVDS, your CPU cycles are yours alone. This is critical when your CI/CD scripts start running automated builds.
Final Thoughts
Moving from SVN to Git requires a shift in mindset, but hosting it shouldn't be a headache. By building your own Git server on a robust Linux VDS, you save on licensing fees, keep your data within the European Economic Area, and ensure your team isn't waiting on trans-Atlantic latency.
Ready to ditch Subversion? Spin up a CentOS 5 instance on CoolVDS today. With our 15k RPM SAS storage and gigabit uplinks, your commits will finish before you can even lift your fingers off the keyboard.