Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Copy a repo without forking

How to copy a GitHub repo without forking

GitHub only lets you fork a repo once, if you want to make more than one copy of a project here's how you can do it. Useful for starter code.

  1. Create a new empty folder for your project and initialize git

    cd where-you-keep-your-projects
    mkdir your-project-name
    cd your-project-name
    git init
  2. "Pull" the repo you want to copy:

    # git url is the same as the clone URL
    git pull git-url-of-the-repo-you-want-to-copy
  3. Create a new repository for your project on GitHub

  4. Push your code to the new repository you just created

    git remote add origin git-url-of-the-new-repo-you-created
    git push -u origin master
Copy link

MarkJeronimus commented Jul 20, 2022

But be warned: This loses the link to the original repository, so if the original is still being developed on, the copy won't show "This branch is # commits behind repo-you-want-to-copy:master."

Copy link

also - you won't have your branches; if the repo has open PRs you will need to find a way to make sure all the branches from the original repo are pushed

Copy link

Thanks so much for this really helpful

Copy link

Nowadays, you might need to use main rather than master in the final command:

git push -u origin main

Copy link

I know there's a heated debate going on making people hate the words master/slave, but naming a branch 'master' has nothing to do with that. The branch doesn't 'control' anything with unjust authority. So I don't get at all why this is changing.

Copy link

klovelyPhraseHealth commented Nov 20, 2022

Agree. It's nonsense that this could be "offensive" to anybody. I wish the offended good luck should they ever read a mechanical engineering textbook.

That, said, I do think main may be the better word, as master implies a slave/agent branch, which isn't really the case. Branches are totally independent of one another; changes to main/master do not dictate changes to other branches or in any way direct or command them per se.

Hence, I think main is slightly more descriptive, and doesn't imply externalities or relationships that don't exist. Rather, the main branch is exactly that - the branch, typically, from which all branches, uh... branch. trunk would have also made sense 🤔


  1. Machinery, Computers. a device or process under control of or repeating the actions of a similar device or process.

I don't mind in this case, because re-naming a branch is incredibly easy. For projects with longstanding PRs, etc., re-naming the branch is not worth the effort. If you are using master, stick with that, unless you have no open PRs and no weird externalities with a re-name. For a large, mature, and active repo, the re-name isn't nearly worth it. If you are dead-set on re-naming, you could merge into master and then subsequently merge master into main in a separate PR. This will allow existing code reviews to be merged as planned without having to re-open them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment