Master Git Worktrees: Set Up a Bare Repository

Learn to Organize Your Git Worktrees with Bare Repositories

In this tutorial, you’ll learn a more organized approach to managing multiple Git worktrees by utilizing bare repositories. We’ll cover what a bare repository is, why it’s beneficial for worktree management, and how to clone one effectively.

Understanding Git Worktrees and Standard Clones

Previously, we explored adding new Git worktrees to an existing repository. When you initially clone a repository from a service like GitHub, Git performs two main actions:

• It clones the repository itself, which includes the hidden .git folder containing all the project’s history, branches, references, hooks, and other metadata.
• It creates a default worktree, checking out the latest commit, usually on the main branch. This is the directory where your project’s code resides and where you’ll do your development.

This standard cloning process results in a project folder containing both the .git directory and your project’s source code.

What is a Bare Repository?

A bare repository is a Git repository that contains only the contents of the .git folder. It does not include a working directory or a checked-out copy of the project’s code. Essentially, it’s just the Git database itself, holding all the history, branches, and metadata, but without any project files present in the repository’s root directory.

Why Use a Bare Repository for Worktrees?

The primary advantage of using a bare repository when you plan to use multiple worktrees from the outset is organization and preventing misuse of the default worktree:

• Prevents a “Junk Drawer”: It stops you from treating the default worktree as a dumping ground for various experiments or unfinished tasks.
• Cleaner Project Structure: It allows you to manage your worktrees in a more structured way. Instead of having worktrees scattered alongside the main project directory, you can keep the bare repository (the .git data) within a dedicated .git folder inside a parent project directory, with each worktree residing alongside it. This creates a much tidier hierarchy.

In the standard cloning method, adding a new worktree often places it outside the main project folder, which can feel disorganized. Using a bare repository approach keeps everything contained within a defined project structure.

How to Clone a Bare Repository

Let’s walk through the process of cloning a bare repository and setting it up for use with worktrees.

Step 1: Get the Repository URL

First, you need the URL of the Git repository you want to clone. You can typically find this on the repository’s page on platforms like GitHub, GitLab, or Bitbucket.

Step 2: Create a Project Directory

Navigate to where you want your project to reside in your terminal. It’s good practice to create a dedicated parent directory for your project. For example, if you’re working on a portfolio project, you might create a directory named portfolio.

Use the following commands:

1. mkdir portfolio
2. cd portfolio

Expert Tip: Using a parent directory like portfolio helps keep related files and worktrees organized under a single umbrella.

Step 3: Clone the Bare Repository

Now, you’ll clone the repository using the git clone command, but with a crucial addition: the --bare flag. You’ll also specify a destination for the bare repository’s data, typically a hidden folder named .git within your project directory.

The command structure is:

git clone --bare <repository_url> <destination_path>

Using our example, it would look like this:

1. Paste the repository URL you copied earlier.
2. Append .git as the destination path.

Example command:

git clone --bare https://github.com/yourusername/your-repo.git .git

Note: If you omit the destination path (e.g., git clone --bare <repository_url>), Git will place the bare repository’s contents directly into the current directory (portfolio in our example). While some developers prefer this, placing it inside a .git folder keeps the top-level project directory cleaner.

Step 4: Verify the Bare Repository Clone

After the clone operation completes, you can verify its contents. Run the ls -a command in your terminal within the portfolio directory.

ls -a

You should see a .git folder. Crucially, you will not see any project code files checked out. This confirms that Git only cloned the repository’s data and did not create a working directory.

Step 5: Confirm No Working Tree Exists

To further confirm that no working tree has been created, try running a Git command that requires one, such as git status, while inside the portfolio directory (but not inside the .git folder).

git status

You should receive an error message indicating that the command must be run within a worktree, as none currently exists.

Step 6: Inspect the Bare Repository Contents (Optional)

If you want to see what’s inside the bare repository’s data folder, navigate into the .git directory and list its contents.

1. cd .git
2. ls

You will find all the standard Git repository files and directories (like HEAD, config, objects, refs, etc.) that normally reside within the .git folder of a standard clone. This confirms that all repository metadata is present.

Warning: Avoid making direct changes inside the .git folder of a bare repository, as this can corrupt your repository data.

After inspection, you can navigate back to your project’s root directory:

cd ..

Conclusion

You have now successfully cloned a bare Git repository. This sets the stage for a more organized workflow when managing multiple worktrees, ensuring your project structure remains clean and manageable. In the next steps, you’ll learn how to effectively use this bare repository setup with your worktrees.

Source: Git Worktrees Tutorial #3 – Bare Repositories (YouTube)