Copy a repo without forking

copy-repo.md

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
   

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."

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

Thanks so much for this really helpful

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

git push -u origin main

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.

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 🤔

from https://www.dictionary.com/browse/slave,

6. 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.