How to Create Git on Linux Server for CI/CD Workflows

To create Git on a Linux server, install Git, add a dedicated “git” user, initialize a bare repository for collaboration, enable SSH key access, and push from your local machine.

This setup provides a secure, lightweight Git server over SSH, ideal for small teams, CI/CD, and private version control without the overhead of full platforms.

In this guide, you’ll learn how to create Git on a Linux server the right way—fast, secure, and production-ready. We’ll cover installing Git, creating a bare repository, setting SSH access, managing permissions for teams, and hardening the server.

Whether you use Ubuntu, Debian, or RHEL-based systems, the steps below are clear and beginner-friendly.

What You’ll Build: A Lightweight Git Server Over SSH

A minimal Git server uses SSH for transport and a dedicated user for repositories. You push and pull using SSH URLs, and each project is a “bare” repository on disk. This is the most stable, secure, and resource-efficient way to host private Git without installing heavy web interfaces.

Prerequisites

• A Linux server (Ubuntu/Debian or RHEL/CentOS/AlmaLinux/Rocky)
• Root or sudo access
• OpenSSH server installed and reachable on port 22
• Local machine with Git installed
• Optional: a domain or static IP for cleaner remote URLs

Step 1: Install Git

Install the latest stable Git from your distro’s repos. For most use cases, the packaged version is sufficient and secure.

Ubuntu/Debian

sudo apt update
sudo apt install -y git

RHEL/CentOS/AlmaLinux/Rocky

sudo dnf install -y git
# or on older systems:
# sudo yum install -y git

Verify installation:

git --version

Step 2: Create a Dedicated Git User

Running Git under a dedicated account improves security and organization. We’ll use the username “git.”

sudo adduser --system --shell /bin/bash --group --disabled-password git
# Create home if not present and set safe permissions
sudo mkdir -p /home/git
sudo chown -R git:git /home/git
sudo chmod 750 /home/git

The “git” user will own all repositories. Team members will connect via SSH to this account or via their own users added to a shared group (explained later).

Step 3: Initialize a Bare Repository on the Server

Bare repositories store Git data without a working tree and are designed for collaboration.

sudo -u git mkdir -p /home/git/repos
sudo -u git git init --bare --shared=group /home/git/repos/myapp.git

The –bare flag creates a repository that’s optimized for pushing and pulling. The –shared=group helps when multiple users (in the same group) contribute to the repo.

Step 4: Configure SSH Key Access

Use SSH keys for secure, passwordless access. Generate a key on your local machine and upload it to the server.

On your local machine

ssh-keygen -t ed25519 -C "you@example.com"
# press enter to accept defaults and set a passphrase

Copy your public key to the server:

ssh-copy-id git@your-server-ip
# or manually:
# cat ~/.ssh/id_ed25519.pub | ssh git@your-server-ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Test login:

ssh git@your-server-ip
# you should land in the git user's home (no sudo privileges)

Step 5: Push an Existing Project to the Server

From your local repository, add the remote and push. Replace host/IP and repo name accordingly.

cd /path/to/local/project
git init
git add .
git commit -m "Initial commit"

git remote add origin git@your-server-ip:/home/git/repos/myapp.git
git push -u origin main
# or 'master' depending on your branch name

Teammates can now clone the repo:

git clone git@your-server-ip:/home/git/repos/myapp.git

Step 6: Manage Collaborators and Permissions (Group-Based)

For multiple users, use a shared Unix group to keep permissions sane and predictable.

# On the server:
sudo groupadd gitgroup
sudo usermod -aG gitgroup git

# Add real users (already existing) to the group:
sudo usermod -aG gitgroup dev1
sudo usermod -aG gitgroup dev2

# Ensure repos are owned by group and writable:
sudo chown -R git:gitgroup /home/git/repos
sudo chmod -R g+ws /home/git/repos

# Set repository-level config to respect group sharing:
sudo -u git git --git-dir=/home/git/repos/myapp.git config core.sharedRepository group

Developers can use their own SSH accounts and clone via their usernames, or you can centrally manage keys in the git user’s authorized_keys. For high security, restrict the git account to Git-only commands using git-shell.

Step 7: Harden and Secure Your Git Server

Firewall

# Ubuntu/Debian (UFW):
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

# RHEL family (firewalld):
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

SSH Hardening

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#PubkeyAuthentication yes/PubkeyAuthentication yes/' /etc/ssh/sshd_config
# Optionally change port, disable root login:
# Port 2222
# PermitRootLogin no
sudo systemctl reload sshd

Consider Fail2ban for brute-force protection and keep your server patched. If SELinux is enforcing, ensure repository paths have correct contexts or place them under /home/git with default contexts.

Troubleshooting Common Issues

• Permission denied (publickey): Ensure your SSH key is in authorized_keys and file permissions on ~/.ssh are correct (700 directory, 600 files).
• fatal: could not create work tree dir: Check directory ownership and that group write is enabled on the repo path.
• Repository not found: Verify the exact path to the bare repo and that it ends with .git.
• Wrong default branch: Use git symbolic-ref HEAD refs/heads/main inside the bare repo or push your desired branch first with -u.
• Slow pushes: Run git gc periodically, and check network latency or CPU/storage performance.

Optional: Lightweight Web Interfaces (When You Need More)

If you want a UI without going full enterprise, consider:

• Gitea: Very light, easy install, built-in issues, PRs, and CI integrations. Great for small to mid teams.
• Gitolite: SSH-key managed permissions and repo control; no web UI, but powerful ACLs.
• GitLab: Feature-rich DevOps platform; requires more CPU/RAM and maintenance.

For many teams, a pure SSH Git server is enough. Add a web interface later if you need code reviews, issues, or CI/CD dashboards.

Best Practices for Production

• Backups: Snapshot /home/git and regularly rsync or use object storage. Test restores!
• Hooks: Use server-side hooks (pre-receive, post-receive) for linting, CI triggers, or branch protections.
• Access hygiene: Remove stale keys, rotate critical keys, and audit authorized_keys periodically.
• Resource upkeep: Keep Git updated, run git gc on large repos, and monitor disk I/O and inode usage.
• Isolation: Run on a dedicated VPS. Avoid mixing critical apps and repos on the same box.

Why Host Your Git on a YouStable VPS

Hosting your Git server on a YouStable VPS gives you predictable performance, full root access, snapshots, and DDoS protection options—perfect for secure, private version control. Spin up an Ubuntu or AlmaLinux instance in minutes, harden SSH, and deploy your Git repos with confidence on infrastructure tuned for developers.

Full Example: From Zero to First Push

# 1) Install Git
sudo apt update && sudo apt install -y git  # Debian/Ubuntu

# 2) Create git user and repo path
sudo adduser --system --shell /bin/bash --group --disabled-password git
sudo -u git mkdir -p /home/git/repos

# 3) Create a bare repository
sudo -u git git init --bare --shared=group /home/git/repos/myapp.git

# 4) Harden SSH (keys only)
ssh-keygen -t ed25519 -C "you@example.com"
ssh-copy-id git@your-server-ip
# optional: disable password auth in sshd_config then reload

# 5) Push from local
cd /path/to/local/project
git init
git add .
git commit -m "Initial commit"
git remote add origin git@your-server-ip:/home/git/repos/myapp.git
git push -u origin main

Key Takeaways

• Use a dedicated git user and bare repositories for clean, safe hosting.
• Prefer SSH keys and disable password logins for security.
• Use a shared group and core.sharedRepository for multi-user collaboration.
• Harden with firewalls, backups, and periodic maintenance.
• Scale up to Gitea or GitLab only if you need advanced workflows and UI.

FAQs