Introduction

Sometimes you need the current contents of a Git repository but not its commit history. That usually happens when you want to publish a clean starting point, hand off source code without internal history, or create a new repository from the current working tree.

Decide Whether You Want Files or a New Git Repository

There are two different goals that people often mix together:

• copy the files only, with no .git directory at all
• create a new Git repository that starts from the current snapshot as its first commit

The first goal is simpler. The second goal adds a fresh history after the copy. Choose the one you actually need before running commands.

Method 1: Export the Current Snapshot

If you only want the files, export the current tree and leave Git metadata behind. One clean option is git archive.

git archive --format=tar HEAD | tar -x -C /tmp/project-copy

This writes the contents of HEAD into another directory without copying .git. The result is just files. No branches, no tags, no reflog, and no prior commits.

This method is good when you need a source snapshot for packaging or for starting a new unrelated project.

If you already have a checked-out working tree and do not care about ignored files, a plain filesystem copy can also work:

rsync -av --exclude='.git' /path/to/original/ /tmp/project-copy/

That version copies the working directory as it exists on disk, which means uncommitted changes are included. git archive only exports committed content from a specific revision.

Method 2: Create a Fresh Repository From the Snapshot

If you want a clean history that starts now, copy the files and then initialize a new repository.

1mkdir /tmp/project-fresh
2cd /tmp/project-fresh
3git archive --format=tar /path/to/original-repo HEAD | tar -x
4
5git init
6git add .
7git commit -m "Initial import"

A more common workflow is to export or copy the files, then connect the new repository to a different remote.

git remote add origin [email protected]:your-org/new-project.git
git branch -M main
git push -u origin main

At that point you have a new repository with one commit and no connection to the old history.

Method 3: Use a Shallow Clone Only if Limited History Is Acceptable

Some people reach for git clone --depth 1. That command reduces history, but it does not remove history completely. It creates a Git repository with a truncated history containing the current state and the latest reachable commit.

git clone --depth 1 [email protected]:example/original.git project-shallow

This is useful when you care about download size or speed, but it does not satisfy a strict “no history” requirement. The repository is still Git-managed, and users can still see commit metadata for the copied revision.

Preserve What Matters Outside History

Removing Git history does not automatically remove everything sensitive. Review the snapshot for:

• secrets committed into config files
• generated artifacts that should not be versioned
• remote URLs inside documentation or scripts
• CI files that refer to the original project

If the goal is legal or organizational separation, also review licenses, ownership notices, and package metadata. A clean Git history is not the same as a clean project handoff.

Common Pitfalls

The biggest mistake is deleting the .git directory inside the original repository instead of inside a copy. That destroys local history and is avoidable. Always work in a new directory.

Another mistake is using git clone --depth 1 when the requirement is truly “no history.” A shallow clone is still a clone and still contains Git metadata.

Developers also forget that git archive ignores uncommitted changes. If you need the exact working tree, use a file copy that excludes .git, or commit the changes before exporting.

Finally, do not assume removing history eliminates secrets. If the current snapshot still contains them, they remain exposed.

Summary

• Decide whether you need only files or a brand new repository with fresh history.
• Use git archive when you want a clean snapshot of committed files.
• Use a filesystem copy excluding .git if you need uncommitted working-tree changes.
• Initialize a new repository after the copy if you want a fresh first commit.
• 'git clone --depth 1 reduces history but does not remove it completely.'