DEV Community

Janak Shrestha
Janak Shrestha

Posted on

Set Up Git Repository on Storage Server

The Nautilus development team has provided requirements to the DevOps team for a new application development project, specifically requesting the establishment of a Git repository. Follow the instructions below to create the Git repository on the Storage server in the Stratos DC:

Utilize yum to install the git package on the Storage Server.
Create a bare repository named /opt/games.git (ensure exact name usage).


Step 1: SSH Into the Remote Server

First, connect to your server from your local machine (or jump host):

ssh natasha@ststor01
Enter fullscreen mode Exit fullscreen mode

When prompted, enter the user's password. Once connected, you'll see something like:

[natasha@ststor01 ~]$
Enter fullscreen mode Exit fullscreen mode

💡 Tip: If your server has a hostname that doesn't resolve, use the IP address instead:

ssh natasha@10.244.164.10

Step 2: Elevate to Root (or Use sudo)

Installing system packages and writing to /opt requires elevated privileges. Switch to the root user:

sudo -i
Enter fullscreen mode Exit fullscreen mode

Your prompt will change to:

[root@ststor01 ~]#
Enter fullscreen mode Exit fullscreen mode

âš ī¸ Security Note: In production environments, prefer using sudo for individual commands rather than staying logged in as root. We use sudo -i here for simplicity.


Step 3: Install Git Using yum

Now install the git package with yum:

yum install -y git
Enter fullscreen mode Exit fullscreen mode

You'll see yum resolve dependencies and install Git along with required packages. Here's what a successful install looks like:

Dependencies resolved.
================================================================================
 Package              Architecture   Version             Repository      Size
================================================================================
Installing:
 git                  x86_64         2.52.0-1.el9        appstream       39 k
Installing dependencies:
 git-core             x86_64         2.52.0-1.el9        appstream      5.0 M
 git-core-doc         noarch         2.52.0-1.el9        appstream      3.1 M
 less                 x86_64         590-6.el9           baseos         162 k
 perl-Error           noarch         1:0.17029-7.el9     appstream       42 k
 perl-Git             noarch         2.52.0-1.el9        appstream       37 k
 perl-TermReadKey     x86_64         2.38-11.el9         appstream       37 k
 perl-lib             noarch         0.65-484.el9        baseos          13 k
================================================================================
...
Complete!
Enter fullscreen mode Exit fullscreen mode

Verify the Installation

Confirm Git is installed and check the version:

git --version
Enter fullscreen mode Exit fullscreen mode

Expected output:

git version 2.52.0
Enter fullscreen mode Exit fullscreen mode

✅ Git is now installed.


Step 4: Create the Bare Repository

This is the core step. We'll use git init --bare to create a repository without a working directory — the correct approach for a central server repo.

git init --bare /opt/games.git
Enter fullscreen mode Exit fullscreen mode

You'll see output similar to:

hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0. To configure the initial branch name
hint: to use in all of your new repositories, which will suppress this warning,
hint: call:
hint:
hint:   git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m <name>
hint:
hint: Disable this message with "git config set advice.defaultBranchName false"
Initialized empty Git repository in /opt/games.git/
Enter fullscreen mode Exit fullscreen mode

🤔 What Is a "Bare" Repository?

Feature Normal Repo Bare Repo
Working directory ✅ Yes ❌ No
.git folder Nested inside project Repo is the folder
Purpose Local development Central server / remote
Created with git init git init --bare

A bare repo is what you'd typically use as the remote on GitHub, GitLab, or a self-hosted Git server. It has no files to edit — only the version history.

â„šī¸ About the "master" Hint Message

Don't panic — that's just a hint, not an error. Git is letting you know its default branch name is master and will become main in Git 3.0. Your repository is fully functional.

To suppress the hint globally in the future:

git config --global init.defaultBranch main
Enter fullscreen mode Exit fullscreen mode

Step 5: Verify the Repository

Confirm the repo was created with the correct structure:

ls -la /opt/games.git
Enter fullscreen mode Exit fullscreen mode

You should see:

total 36
drwxr-xr-x 6 root root 4096 Oct  5 09:20 .
drwxr-xr-x 1 root root 4096 Oct  5 09:20 ..
-rw-r--r-- 1 root root   23 Oct  5 09:20 HEAD
-rw-r--r-- 1 root root   66 Oct  5 09:20 config
-rw-r--r-- 1 root root   73 Oct  5 09:20 description
drwxr-xr-x 2 root root 4096 Oct  5 09:20 hooks
drwxr-xr-x 2 root root 4096 Oct  5 09:20 info
drwxr-xr-x 4 root root 4096 Oct  5 09:20 objects
drwxr-xr-x 4 root root 4096 Oct  5 09:20 refs
Enter fullscreen mode Exit fullscreen mode

What Each Entry Means

Entry Purpose
HEAD Points to the default branch (master)
config Repository configuration settings
description Human-readable description (used by GitWeb)
hooks/ Server-side hook scripts (pre-receive, post-receive, etc.)
info/ Contains exclude patterns and refs info
objects/ Stores all commits, trees, and blobs
refs/ Branch and tag references

Notice there are no source files — that's exactly what makes this a bare repo. ✅

Confirm "Bare" Mode Is Enabled

Check the config file:

cat /opt/games.git/config
Enter fullscreen mode Exit fullscreen mode

Expected output:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
Enter fullscreen mode Exit fullscreen mode

The key line is bare = true — this confirms Git treats it as a server-side repository. ✅


Step 6 (Optional): Set Ownership for Team Access

If multiple team members need to push/pull, adjust ownership and permissions:

chown -R natasha:natasha /opt/games.git
chmod -R 755 /opt/games.git
Enter fullscreen mode Exit fullscreen mode

For a shared team, consider creating a dedicated git group:

groupadd git
usermod -aG git natasha
chown -R :git /opt/games.git
chmod -R 775 /opt/games.git
Enter fullscreen mode Exit fullscreen mode

Step 7 (Optional): Test the Repository From Another Machine

From any other server with SSH access and Git installed, try cloning:

git clone natasha@ststor01:/opt/games.git
Enter fullscreen mode Exit fullscreen mode

You'll see:

Cloning into 'games'...
warning: You appear to have cloned an empty repository.
Enter fullscreen mode Exit fullscreen mode

This warning is expected — you've cloned a fresh, empty bare repo. Everything is working. 🎉


Recap: What We Did

Step Action
1 SSH'd into the remote server
2 Elevated privileges with sudo -i
3 Installed Git via yum install -y git
4 Created the bare repo with git init --bare /opt/games.git
5 Verified the repo structure and bare = true config
6 (Optional) Set ownership for team access
7 (Optional) Tested cloning from another machine

Common Pitfalls to Avoid

  • ❌ Forgetting --bare → creates a normal repo, which breaks push workflows (you'll see "refusing to update checked out branch" errors).
  • ❌ Using the wrong path → task requirements often specify exact paths like /opt/games.git; a typo means failure.
  • ❌ Not using sudo → permission denied when writing to /opt.
  • ❌ Confusing the hint message with an error → the master hint is harmless.

Conclusion

You now have a fully functional bare Git repository hosted on a remote Linux server, ready to be used as a central code hub for your team. This setup forms the backbone of self-hosted Git workflows and is a fundamental skill for any DevOps engineer.

From here, you can:

  • Add Git hooks for CI/CD automation
  • Configure SSH key authentication for passwordless access
  • Front it with Gitolite or Gitea for a full-featured experience
  • Wire it into a Jenkins pipeline for automated builds

Top comments (0)