Skip to content

DevOps Day 21: Creating a Central Git Repository

Today's task was about laying the foundation for any collaborative software project: setting up the central, shared Git repository. This is the "single source of truth" where all team members will send their code and from which they will pull updates.

I learned the crucial difference between a regular Git repository on my own machine and a special "bare" repository that is designed to live on a server. The process involved installing the Git software and then using a specific git init command to create this central hub. This document is my detailed, first-person guide to that entire process.

Table of Contents

The Task

My objective was to prepare the Storage Server to act as a Git server. The specific requirements were: 1. Install the git package using the yum package manager. 2. Create a bare Git repository named /opt/official.git.

My Step-by-Step Solution

The process was very straightforward and performed entirely on the command line of the Storage Server.

Step 1: Connect and Install Git

First, I needed to get onto the correct server and ensure the Git software was available. 1. I connected to the Storage Server: ssh natasha@ststor01. 2. I installed the git package using yum. I needed sudo because installing software is an administrative action. 

sudo yum install -y git

Step 2: Create the Bare Repository

This was the core of the task. I used the git init command with the --bare flag. 1. I ran the command to create the repository in the /opt directory. I needed sudo again because /opt is a system directory owned by root. 

sudo git init --bare /opt/official.git

Step 3: Verification

The final and most important step was to confirm that the repository was created correctly. A bare repository is not empty; it's filled with Git's internal tracking files. 1. I listed the contents of the new directory. 

ls -l /opt/official.git
2. The output showed a list of files and directories like HEAD, config, objects, refs, and hooks. This was the definitive proof that I had successfully created a bare repository, not a regular one with a working directory.

Why Did I Do This? (The "What & Why")

- Git: Git is a distributed version control system. It's the industry standard for tracking changes in source code during software development. It allows multiple developers to work on the same project without stepping on each other's toes. - Central Repository: While Git is "distributed" (meaning every developer has a full copy of the history), teams need a central, agreed-upon place to synchronize their work. This task was about creating that central hub. - Bare Repository: This is the key concept. A bare repository is a special type of Git repository that is used exclusively for sharing. It contains no working files (the files you can see and edit). It only contains the version history data, which is normally hidden inside the .git directory. - Why is this important? You never want to have a working copy of the files on your central server. If you did, a developer could push their changes, but this would not update the visible files. If someone else were to log in and edit those visible files, it would create a massive conflict and corrupt the repository's state. A bare repository prevents this by having no working files to edit. Its only job is to receive and serve Git data. The .git naming convention (official.git) is the standard way to signal that a repository is bare.

Deep Dive: Bare vs. Non-Bare (Working) Repositories

This task perfectly highlighted the difference between the two types of Git repositories.

[Image of a central bare Git repository with developers pushing and pulling]

Feature Bare Repository Non-Bare (Working) Repository
Purpose Central hub for sharing code. The "single source of truth." A developer's local workspace for coding and committing.
Location On a shared server (like my Storage Server). On a developer's local machine.
Working Files None. You cannot see or edit the project files directly. Yes. Contains all the project files that you can edit.
Structure Looks like the contents of a .git directory (HEAD, objects, refs, etc.). Looks like a normal project folder, with a hidden .git subdirectory inside.
Creation Command git init --bare git init or git clone
Allowed Actions Can receive push operations from developers. Cannot receive push operations. You can only commit locally.

Common Pitfalls

- Forgetting --bare: The most critical mistake would be to run sudo git init /opt/official.git without the --bare flag. This would create a non-bare repository with a working directory and a .git subfolder, which is completely wrong for a central server and would cause push operations to fail later. - Permissions Issues: The /opt directory is owned by root. Forgetting to use sudo when running the git init command would result in a "Permission denied" error. - Not Installing git First: Trying to run git init before running sudo yum install -y git would fail with a "command not found" error.

Exploring the Commands Used

- sudo yum install -y git: A standard Linux command to install software. - sudo: Executes the command with superuser (administrator) privileges. - yum: The package manager for this RHEL-based system. - -y: Automatically answers "yes" to any confirmation prompts. - git: The name of the package to install. - sudo git init --bare /opt/official.git: The primary command for this task. - git init: The command to initialize a new Git repository. - --bare: The crucial flag that tells Git to create a repository for sharing, with no working files. - /opt/official.git: The path where the new bare repository directory will be created. - ls -l /opt/official.git: A standard Linux command to list the contents of a directory in long format. I used this to verify that the repository was created and that it contained the expected internal Git files, confirming it was a bare repository.