Earlier this month, I wrote about CopyGitHubRepo, a PowerShell utility I had been building to create clean copies of GitHub repositories without automatically carrying their history forward.

Today the project reached its next milestone.

CopyGitHubRepo v0.1.0 is now officially released and available from the PowerShell Gallery.

The previous article focused on why I built the tool, the difference between Snapshot and FullHistory modes, and the safety decisions behind the project.

This release is about getting that work into a form that other people can install and use.

Installing CopyGitHubRepo

The recommended installation method is now the PowerShell Gallery.

Install-PSResource CopyGitHubRepo
Import-Module CopyGitHubRepo

Once installed, the easiest place to start is the guided wizard:

Start-CopyGitHubRepositoryWizard

For systems still using PowerShellGet, the module can also be installed with:

Install-Module CopyGitHubRepo -Scope CurrentUser

The project currently requires PowerShell 7.4 or newer, Git, and the GitHub CLI. Git LFS is also required when the repository being copied contains LFS-managed content.

What Shipped in v0.1.0

The first stable release includes quite a bit more than the original repository-copying script.

At the center of the project are the two repository copy modes.

Snapshot creates a new repository containing the current state of the source repository’s default branch as a single new root commit.

FullHistory preserves normal Git history, branches, tags, the default branch, and reachable Git LFS objects.

Both modes are exposed through the scriptable Copy-GitHubRepository command, while the guided wizard provides an interactive workflow for people who want to review their choices before anything changes.

The release also includes:

  • repository discovery through GitHub CLI and the GitHub API;
  • non-mutating planning with -PlanOnly;
  • PowerShell -WhatIf support;
  • Git LFS handling;
  • same-name repository replacement with archive-first protection;
  • repository settings restoration;
  • post-copy verification;
  • Markdown and JSON execution reports;
  • durable recovery reports when failures occur after mutation has started.

One of the main goals of the project has been to make repository operations predictable.

The tool should tell you what it plans to do, require explicit authority for destructive operations, perform the requested work, and then verify the result.

The Guided Workflow

For interactive use, the wizard is the recommended entry point:

Start-CopyGitHubRepositoryWizard

The wizard walks through repository selection and copy options, allows Back, Next, and Cancel navigation, and eventually displays the same real migration plan generated by Copy-GitHubRepository -PlanOnly.

Nothing is changed until the user explicitly chooses to execute the operation.

For automation or repeatable scripting, the deterministic API remains available directly:

Copy-GitHubRepository `
    -SourceRepository infoconex/source `
    -DestinationRepository infoconex/destination `
    -PlanOnly

After reviewing the plan:

Copy-GitHubRepository `
    -SourceRepository infoconex/source `
    -DestinationRepository infoconex/destination

That separation between an interactive experience and a deterministic underlying command was important to me.

The wizard should make the tool easier to use without turning the core repository operation into something that depends on interactive behavior.

Tested Across Platforms

Getting to v0.1.0 also meant moving beyond testing the happy path on a single machine.

The project quality gate now runs on:

  • Windows;
  • Ubuntu;
  • macOS.

The release has also been validated against real GitHub repositories for scenarios including Snapshot copies, FullHistory copies, Git LFS, same-name replacement, repository settings restoration, and recovery behavior.

The PowerShell Gallery package itself is validated before publication as well, including module imports and the expected public command surface.

For a tool that can create and rename repositories, I wanted the release process to receive the same attention as the repository-copy logic.

A Proper Release Pipeline

Publishing v0.1.0 also completes another piece of the project that isn’t immediately visible when using the module: the release pipeline.

Stable releases are tied to version tags rather than simply publishing whatever happens to be on main.

The release process validates the version, runs the quality gate, builds the package, publishes it to the PowerShell Gallery, and creates the corresponding GitHub release artifacts.

That gives the project a repeatable path for future versions instead of making each release a collection of manual steps.

Documentation

I also created a dedicated documentation site for the project.

The documentation includes the user guide, command reference, architecture, product behavior, installation security, support policy, contributor information, and release documentation.

If you only want to install the tool and get started, you don’t need to read all of that.

But for repository tooling, I think it is useful to document not only what a command does, but also what it intentionally does not do.

The safety boundaries are part of the product.

Try It

CopyGitHubRepo v0.1.0 is available now.

If you want more detail on why the tool uses Snapshot as its default, how it differs from forks, mirrors, and templates, or why planning and verification are central to the design, take a look at my earlier article: Copy GitHub Repo – Clean Snapshots Without Carrying History.

For this release, though, the main thing is simple:

CopyGitHubRepo is no longer just a project I am building. Version 0.1.0 is published, documented, and ready to install.