Stop Bleeding Efficiency with Centralized Version Control
If I have to resolve one more Subversion tree conflict caused by a network timeout, I might just pull the dedicated server plug myself. It is 2010. Distributed Version Control Systems (DVCS) are not a fad; they are the baseline for sanity. While GitHub is gaining traction, many of us operating under strict Norwegian data compliance standards (referencing the Personopplysningsloven) cannot simply dump proprietary code onto US servers. Safe Harbor is a legal framework, not a guarantee against industrial espionage.
You need a private Git server. You need it locally hosted. And you need it to be fast.
We are going to set up a rock-solid Git host using CentOS 5.4 and raw SSH. No fancy web UIs that eat RAM, no bloated management scripts. Just pure, unadulterated Linux performance. We deploy this architecture on CoolVDS because we need guaranteed RAM and strict I/O isolation—something standard OpenVZ overselling containers often fail to deliver.
The Hardware Reality: Latency Kills Flow
When you run git push, the negotiation phase is chatty. If your server is sitting in a datacenter in Texas and your dev team is in Oslo, you are fighting physics. Packets have to travel.
I recently migrated a client from a budget US host to a CoolVDS Xen instance peering directly at NIX (Norwegian Internet Exchange). Their clone times for a 400MB repository dropped from 4 minutes to 45 seconds. That isn't just bandwidth; that's the result of low latency TCP handshakes.
Prerequisites
- OS: CentOS 5.4 (or Debian Lenny if you prefer apt)
- RAM: 512MB minimum (Git packs can be memory intensive)
- Storage: RAID-10 SAS recommended. CoolVDS offers high-performance storage that handles concurrent disk writes better than standard SATA drives.
Step 1: The Setup
First, get your box updated. We don't want old libraries slowing us down.
yum update -y
yum install git-core openssh-server
If git-core isn't in your base repo, grab the EPEL repository. Do not compile from source unless you enjoy dependency hell. We want maintainability, not a science experiment.
Step 2: The 'Git' User
Security 101: Never run services as root. We create a dedicated user for version control. This also makes setting up SSH keys significantly cleaner.
useradd git
passwd git
Step 3: SSH Keys (The Only Auth You Should Trust)
Forget passwords. They are weak, and developers forget them. We use RSA keys. On your local machine (the developer's laptop), generate a key pair if you haven't already:
ssh-keygen -t rsa -C "developer@coolvds-client.no"
Now, on the server, we create the authorized keys structure:
su - git
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
Paste your developers' public keys (id_rsa.pub) into that authorized_keys file, one per line. This is the simplest, most robust access control available.
Pro Tip: If you are managing a team larger than 5 people, manually editing a text file gets tedious. Look into Gitosis. It uses a git repo to manage the configuration of your git server. It's Python-based and standardizes access control without needing shell accounts for everyone.
Step 4: The Bare Repository
Here is where SVN users get confused. On the server, we want a "bare" repository. It contains the version history but no working tree (no actual source files visible). This prevents the awkwardness of pushing to a directory where someone is actively editing files.
cd /home/git
mkdir project.git
cd project.git
git init --bare
That's it. Your server is ready.
Step 5: The Client Side
Back on your local machine, add this new remote and push.
cd myproject
git init
git add .
git commit -m "Initial commit"
git remote add origin git@your-coolvds-ip:project.git
git push origin master
Why Infrastructure Matters
You might think, "Can't I just run this on an old desktop in the office?" You could. But what happens when the power grid fluctuates or the office cleaning crew unplugs the router?
Data integrity requires reliable power and redundant storage. CoolVDS utilizes enterprise-grade hardware with ECC RAM. When Git calculates SHA-1 hashes to verify file integrity, bit rot in bad RAM can corrupt your entire history. We have seen it happen. It is ugly.
Furthermore, local Norwegian hosting ensures you aren't routing sensitive intellectual property through foreign jurisdictions unnecessarily. Datatilsynet is watching, and your clients appreciate the diligence.
Final Hardening
Before you go live, disable shell access for the git user. You only want them using git-shell, not browsing your server via SSH.
Edit /etc/passwd via vipw and change:
git:x:1001:1001::/home/git:/bin/bash
to
git:x:1001:1001::/home/git:/usr/bin/git-shell
Secure. Fast. Owned by you. Deploy a CoolVDS instance today and stop waiting on network latency.