Skip to content

Git Day 2: Cloning a Repository and Navigating Permissions

My second day with Git focused on the most common starting point for any developer joining a project: cloning the central repository. The task was to create a local, working copy of a bare repository that was already on the server.

This exercise turned out to be a fantastic lesson in Linux file permissions and the precise syntax of Git commands. I learned not just how to clone, but also why certain commands fail and how to troubleshoot them.

Table of Contents

The Task

On the Storage Server, I needed to clone an existing bare repository. 1. Source Repository: /opt/blog.git 2. Destination Directory: /usr/src/kodekloudrepos

My Solution & Command Breakdown

After some trial and error, I discovered the correct two-step process to satisfy the lab's requirements, which were very specific about file ownership.

1. Clone the Repository

This command creates a copy of the blog.git repository inside the new /usr/src/kodekloudrepos directory.

sudo git clone /opt/blog.git /usr/src/kodekloudrepos

2. Change the Ownership

Because I ran the first command with sudo, the new directory was owned by root. The lab's validation script required it to be owned by my user, natasha. This command recursively changes the owner.

sudo chown -R natasha:natasha /usr/src/kodekloudrepos

My Learning Journey: Failures & Solutions

My path to the solution was filled with valuable lessons.

  • Failure 1: "Permission Denied".

    • My Initial Thought: My first instinct was to navigate to the parent directory (cd /usr/src/kodekloudrepos) and then run git clone /opt/blog.git blog.
    • The Symptom: This failed with fatal: could not create work tree dir 'blog': Permission denied.
    • The Reason: The /usr/src/kodekloudrepos directory (and its parent /usr/src) is owned by the root user. My user, natasha, did not have permission to create new files or folders inside it. This taught me a crucial lesson about Linux permissions.
    • The Solution: I realized I needed to use sudo to elevate my privileges for the operation.

  • Failure 2: The lab check failed even with the correct clone command.

    • My Action: I successfully ran sudo git clone /opt/blog.git /usr/src/kodekloudrepos. I verified it with ls -la and saw the hidden .git directory. Everything looked perfect.
    • The Symptom: The lab's validation script still failed.
    • The Reason: This was a subtle "gotcha." When you run a command with sudo, the new files and directories it creates are owned by root. The validation script was likely checking for ownership by the user natasha.
    • The Solution: I added the final, critical command: sudo chown -R natasha:natasha /usr/src/kodekloudrepos. This changed the ownership of the cloned directory back to my user, satisfying the picky validation script.

  • Observation: "total 0" and the "empty repository" warning.

    • Symptom: After cloning, ls -l showed total 0, and the clone command gave a warning: You appear to have cloned an empty repository.
    • Reasoning: This was not an error! The source repository (/opt/blog.git) had been created but never had any files committed to it. Therefore, my clone was a perfect copy of an empty project.
    • Verification: The real proof of success was running ls -la (list all), which revealed the hidden .git directory. This folder is the heart of the repository, and its presence confirmed the clone was successful.

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

The git clone command is the starting point for all collaborative work in Git. It creates a local, "working" copy of a central repository. This allows me to: - Have an isolated environment to write and test code without affecting the main project. - Make commits to my local copy to save my progress. - Stay connected to the central repository (referred to as origin) to pull updates from my teammates and push my own completed work back for them to use.

Deep Dive: The Working Copy and the .git Folder

Cloning a repository creates a working copy (or working directory). Unlike the bare repository on the server, a working copy contains both the visible project files and the hidden .git directory.

  • Visible Files: These are the actual source code files you edit (e.g., index.html, style.css). Since my source repo was empty, this area was also empty.
  • The .git Directory: This hidden folder is the engine of the repository. It contains all the history, commit logs, branch information, and configuration needed to track changes and communicate with the central server. The presence of this folder is what makes a normal directory a Git repository.

Exploring the Commands Used

- git clone [source] [destination]: The fundamental command to copy a repository. - [source]: The URL or path to the repository you want to copy. - [destination]: An optional argument. If you provide it, Git creates a folder with that name and puts the repository inside. If you omit it, Git creates a folder with the same name as the source repository. - chown -R [user]:[group] [directory]: A standard Linux command to change the owner of files and directories. The -R (recursive) flag is crucial, as it applies the change to the directory and everything inside it.