How to Fork a Repository on GitHub: A Complete Guide

• A fork creates a full server-side copy under your GitHub username, not just a local download.
• The forked repository shows a distinctive “forked from” indicator linking back to the original.
• GitHub does not permit direct forking of your own repository to the same account—clone or use mirror methods instead.
• Private repositories cannot be forked through GitHub’s standard interface; alternative methods exist for specific scenarios.
• Each fork operates independently, requiring separate synchronization with upstream if updates are needed.
• The fork relationship enables pull requests, allowing proposed changes to flow back to the original project.

How Do I Fork a Repository on GitHub?

Standard Forking Process (Web Interface)

Log in to your GitHub account and navigate to the repository you wish to fork. The repository must be public or accessible to your account. Locate the Fork button positioned in the upper right corner of the repository page, near the navigation bar.

After clicking Fork, GitHub prompts you to select a destination. Choose your personal account or an organization you belong to. The forking process typically completes within seconds, depending on repository size and server load.

The newly created fork appears immediately under your account, displaying a “forked from” badge that identifies the source repository. This badge provides a clickable link back to the original project.

Alternative Methods: CLI and Desktop

For users preferring command-line workflows, GitHub CLI offers a streamlined alternative. The command gh repo fork initiates the forking process directly from the terminal, automatically configuring the remote settings.

GitHub Desktop users can fork through the web interface first, then clone the fork locally via File > Clone Repository. Paste the fork URL, select a local destination folder, and confirm the operation.

What Is the Difference Between Fork and Clone on GitHub?

The fundamental distinction lies in where the copy exists. A fork creates a new repository on GitHub’s servers under your account, while a clone downloads an existing repository to your local machine without creating a server-side copy.

Choose forking when you plan to contribute changes back to the original project through a pull request. The fork creates the necessary repository relationship that GitHub uses to track and propose code contributions.

Choose cloning when you need a local working copy for development, debugging, or personal use without requiring the ability to submit changes upstream. Cloning works with any repository you can access, regardless of ownership.

Both operations preserve the complete history and all branches of the source repository, but their subsequent behaviors differ significantly regarding synchronization and contribution workflows.

Fork vs. Branch: Understanding the Trade-offs

Branches exist within a single repository and require write access to that repository. Forks provide an alternative when you lack direct write permissions, creating a separate workspace where you can develop freely before requesting to merge your changes back.

Projects with strict contribution guidelines often require forks because they allow maintainers to review and approve modifications before integration. This workflow protects the main codebase from unchecked changes while enabling external contributions.

What Does Forking a Repo Do and Why Do It?

When you fork a repository, GitHub generates a complete copy of all files, folders, commit history, branches, and settings. This copy lives independently on GitHub’s servers, disconnected from the original in terms of direct synchronization—your changes don’t automatically update the source, nor do source updates automatically reach your fork.

Open source maintainers benefit from forks because they enable community contributions without granting direct repository access to contributors. This model scales across thousands of simultaneous contributors, each working within their own isolated fork.

Developers also use forks for experimentation, creating variations of projects for personal use, or building derivatives that may never intend to merge back upstream. The fork serves as a complete starting point for independent development trajectories.

What Happens When You Fork a Repository?

The forking process copies every aspect of the repository’s current state. Subsequent commits to the original repository don’t automatically appear in your fork. Your fork retains its connection metadata, showing its origin, but evolves independently.

GitHub records the fork relationship in its database, enabling features like the pull request comparison interface. When you submit a pull request from your fork, GitHub automatically identifies the appropriate source and target repositories.

What to Do After Forking a Repo?

After creating a fork, the typical workflow involves cloning it locally, creating a working branch, making your modifications, and then pushing those changes back to your fork before initiating a pull request to the upstream repository.

Cloning Your Fork Locally

Navigate to your forked repository on GitHub and click the Code button. Choose your preferred protocol—HTTPS, SSH, or GitHub CLI—and copy the repository URL. Open your terminal and execute git clone followed by the copied URL. The command downloads the repository to your current working directory.

Verify your remote configuration by running git remote -v. This displays the fetch and push URLs, showing that your fork is configured as the “origin” remote. If you plan to synchronize with the original repository, you’ll need to add an upstream remote separately.

Creating multiple local clones of the same fork does not cause conflicts. Each clone operates independently, but remember to pull updates regularly with git pull to avoid working with outdated code.

Creating a Branch for Your Changes

Never develop directly on the main branch. Create a dedicated branch for each set of related changes using git checkout -b branch-name. This keeps your main branch clean and aligned with the upstream repository, simplifying future synchronization.

After committing your changes locally, push the branch to your fork with git push origin branch-name. GitHub displays your new branch immediately in the repository’s branch selector.

Submitting a Pull Request

With your changes pushed to your fork, navigate to your fork on GitHub. GitHub typically displays a prominent prompt to create a pull request. Click “Compare & pull request” to open the submission interface.

Select the upstream repository as the destination and choose the appropriate base branch. Write a clear description explaining what your changes accomplish and why they benefit the project. Submit the pull request to notify the maintainers.

The upstream maintainers review your proposal, may request modifications, and ultimately decide whether to merge your changes into the original repository.

Keeping Your Fork Synchronized

Add the upstream repository as a remote with git remote add upstream followed by the original repository’s URL. Fetch the latest changes with git fetch upstream, then switch to your main branch and merge the upstream changes.

Resolve any merge conflicts that arise, commit the resolution, and push the updated main branch to your origin. Repeat this process regularly to keep your fork current with the evolving upstream project.

The Forking Workflow: Step by Step

1. Navigate to the repository you want to fork on GitHub. The repository must be public or accessible to your account.
2. Click the Fork button located in the upper right corner of the repository page.
3. Select your account or organization as the destination for the fork.
4. Wait for creation—the process typically takes a few seconds.
5. Clone your fork locally using git clone with the fork’s URL.
6. Create a working branch for your intended changes.
7. Make, commit, and push your modifications to your fork.
8. Submit a pull request comparing your fork to the upstream repository.

Video tutorials demonstrate this full process, typically spanning seven to eight minutes from navigation through pull request submission.

Clarifying Common Uncertainties

The Context Behind GitHub Forks

GitHub introduced the fork model to solve a fundamental challenge in open source development: how to enable contributions without compromising repository security or requiring constant maintainer intervention. The approach draws from distributed version control principles, where each contributor maintains their own complete copy of the project.

This model has become essential to modern open source collaboration. Platforms like GitHub, GitLab, and Bitbucket all implement fork-based workflows, recognizing that independent workspaces accelerate contribution while maintaining project stability.

For organizations, forks provide an additional layer of isolation between internal development and external collaboration. Teams can work on forks without exposing unfinished work publicly until changes are ready for review.

A fork creates a new copy of an existing repository, sharing code and visibility settings with the original upstream repository. It enables experimentation with changes without affecting the original, particularly in open source collaboration.

— GitHub Documentation

Summary

Forking a repository on GitHub establishes a complete, independent copy under your account, enabling safe experimentation and structured collaboration. The process takes seconds through the web interface, with additional steps required to clone locally, create branches, and ultimately submit changes via pull requests.

Understanding when to fork versus clone or branch determines your workflow efficiency. Forks serve open source contributions and independent development, while clones suit local work and branches address in-repository organization.

Maintaining your fork requires periodic synchronization with the upstream repository, a manual process that keeps your copy current with the evolving source project.

Frequently Asked Questions