Last Updated:

How to Create a Second Fork of a GitHub Project: Step-by-Step Guide

GitHub is a powerful platform for collaborative software development, and forking a repository is a common workflow to contribute to open-source projects or work on personal modifications. However, GitHub enforces a one-fork-per-user-per-repository limit, meaning you can’t directly fork the same project twice using the standard "Fork" button.

But what if you need a second fork? Common scenarios include:

  • Testing experimental features without affecting your main fork.
  • Maintaining separate versions for different clients or environments.
  • Isolating work for distinct teams or projects.

This guide will walk you through creating a functional "second fork" by manually setting up a new repository and syncing it with the original project. While not an official GitHub fork, this approach replicates the fork workflow, allowing you to collaborate and sync updates seamlessly.

Table of Contents#

  1. Prerequisites
  2. Why Create a Second Fork?
  3. Step-by-Step Guide
  4. Troubleshooting Common Issues
  5. Conclusion
  6. References

Prerequisites#

Before starting, ensure you have:

  • A GitHub account.
  • Git installed on your local machine.
  • Basic familiarity with Git commands (e.g., clone, remote, push, pull).
  • Access to the original GitHub repository (the one you want to "fork" a second time).

Why Create a Second Fork?#

While GitHub’s one-fork limit works for most cases, a second fork becomes necessary for:

  • Isolation: Testing risky changes without impacting your main fork’s stability.
  • Client/Environment Specifics: Maintaining separate codebases for different clients or deployment environments (e.g., staging vs. production).
  • Collaboration: Working on distinct features with separate teams, each requiring their own fork-like workflow.

Step-by-Step Guide#

Step 1: Create a New Empty Repository on GitHub#

First, create a blank repository on GitHub to act as your "second fork." This repo will mirror the original project and sync with it over time.

  1. Go to GitHub.com and log in.
  2. Click the "+" icon in the top-right corner and select "New repository".
  3. Fill in the repository details:
    • Repository name: Use a descriptive name (e.g., original-repo-second-fork).
    • Description: Optional, but helpful (e.g., "Second fork for experimental features").
    • Visibility: Choose "Public" or "Private" (match the original repo’s visibility if needed).
    • Important: Uncheck "Add a README file" and "Add .gitignore" (we’ll push the original code later to avoid conflicts).
  4. Click "Create repository".

You’ll now see a page with instructions to push code to this new repo. Keep this tab open—you’ll need the repository URL shortly.

Step 2: Clone the Original Repository Locally#

If you don’t already have a local copy of the original repository, clone it to your machine. If you do, skip to Step 3.

  1. Open your terminal/command prompt.
  2. Navigate to the directory where you want to store the project.
  3. Run:
    git clone https://github.com/original-owner/original-repo.git  
    Replace original-owner and original-repo with the actual owner and repository name (e.g., torvalds/linux).
  4. Navigate into the cloned directory:
    cd original-repo  

Step 3: Add the New Repository as a Remote#

Next, link your local clone to the new GitHub repository you created (your "second fork").

  1. In the terminal, list existing remotes to avoid conflicts:

    git remote -v  

    You’ll see origin (the original repo, if cloned directly) or your first fork (if you cloned your existing fork).

  2. Add the new repository as a remote. Use a clear name like second-fork for easy reference:

    git remote add second-fork https://github.com/your-username/your-new-repo.git  

    Replace your-username and your-new-repo with your GitHub username and the name of the repo you created in Step 1.

  3. Verify the new remote was added:

    git remote -v  

    You should see second-fork listed with the URL of your new repo.

Step 4: Push the Original Code to the New Repository#

Now, push the original project’s code to your new repository to initialize your "second fork."

  1. Ensure you’re on the main branch (or the default branch of the original repo, often main or master):

    git checkout main  
  2. Push the code to your new repository:

    git push -u second-fork main  
    • The -u flag sets second-fork/main as the upstream branch, so future pushes to this branch can use git push without extra arguments.
  3. Refresh the new repository page on GitHub. You’ll now see all files from the original repo—your "second fork" is initialized!

Step 5: Configure the "Upstream" Remote for Syncing#

To keep your second fork updated with changes from the original repository, link the original repo as an "upstream" remote.

  1. Add the original repository as the upstream remote (if not already added):

    git remote add upstream https://github.com/original-owner/original-repo.git  
    • If you cloned your first fork earlier, origin might point to your first fork. In that case, upstream should still point to the original repo.
  2. Verify the upstream remote:

    git remote -v  

    You should see upstream linked to the original repo’s URL.

Step 6: Sync Your Second Fork with the Original Repository#

To pull updates from the original repo into your second fork, use the upstream remote to sync:

  1. Fetch the latest changes from the original repo:

    git fetch upstream  
  2. Merge the upstream changes into your local main branch:

    git merge upstream/main  

    (Replace main with the original repo’s default branch if different.)

  3. Push the synced changes to your second fork:

    git push second-fork main  

Your second fork is now updated with the latest code from the original repository! Repeat these steps whenever you need to sync.

Step 7: Work with Both Forks (Optional)#

If you already have a first fork and want to work with both, manage your remotes carefully:

  • First fork: Typically named origin (if you cloned it initially).
  • Second fork: Named second-fork (as set in Step 3).
  • Upstream: The original repo (to sync both forks).

To push changes to your first fork:

git push origin main  

To push changes to your second fork:

git push second-fork main  

To switch between forks, use git checkout with branch names (e.g., git checkout feature-branch-second-fork for work specific to the second fork).

Troubleshooting Common Issues#

"Remote already exists" Error#

If you see fatal: remote second-fork already exists when adding the remote, run:

git remote rm second-fork  

Then re-add the remote with the correct URL.

Merge Conflicts During Sync#

If git merge upstream/main causes conflicts, resolve them manually:

  1. Open the conflicting files, edit them to resolve issues (look for <<<<<<< HEAD markers).
  2. Stage the resolved files:
    git add <conflicting-file>  
  3. Complete the merge:
    git commit -m "Resolve merge conflicts with upstream"  

Permission Denied When Pushing#

If you get a "permission denied" error, ensure you have access to the new repo (check GitHub repo settings) and that you’re logged into Git with the correct account:

git config --global user.email "[email protected]"  
git config --global user.name "Your Name"  

Conclusion#

While GitHub doesn’t natively support multiple forks, you can create a functional "second fork" by manually setting up a new repository, linking it to the original project, and syncing with Git. This workflow lets you isolate work, collaborate on distinct features, or manage client-specific versions—all while keeping your codebase updated with the original project.

By following these steps, you’ll master remote management, syncing, and troubleshooting, empowering you to handle complex development scenarios with confidence.

References#