How To Fork Your Own GitHub Repository
Creating a distinct child of an existing repository
Background
I’ve been working on a .NET Core boilerplate project on and off for the last two months, though development on it has slowed considerably since my classes have started up again. More recently I decided I wanted to create a React flavor of this repository — initially I had it as a branch, but quickly decided I wanted it to be it’s own independent thought. I didn’t want to have to clone a branch or something like that — I should just be able to find the repository and clone it, run the setup script and be done with it.
On top of that, I wanted this React version of the boilerplate project to be able to get changes from the original project. For instance, I’m working on adding integration testing to my project. When I have that feature implemented, I should just be able to update the React repository by pulling from the original one so it can benefit from the additions.
The Problem
Forking is really simple on GitHub. You find the repository you want to fork, press the button, and blam! Done — you have your own fork of that project.
With your own projects it’s not so easy because forking a project creates a new repository with the same name, and GitHub does not allow you to have repositories with duplicate names.
Forking Your Repository
The process was actually fairly painless once I figured out what needed to happen. It’s important to note you’re not truly forking your original repository, you’re more setting up a new repository with a remote reference to the original.
The steps are pretty straightforward. They presuppose you have already created your new “forked” repository on GitHub and are ready to go with it.
//clone your new repository
git clone <new repository>.git//navigate to the repository root
cd <new repository>//add a reference to your original repository
git remote add upstream <original repository>.git//pull all code from the original repository
git pull upstream master//push all code to the new repository
git push origin master
Once you find your repository on GitHub you should see that all the contents, as well as commit history for the original repository are now in your new one.
You should now be able to make changes in the original repository and then pull in the new one to merge in all those changes.
git pull upstream masterYou may run into merge conflicts here and there, but they should be minimized by more or less treating these repositories as branches where the original one is a parent to the new one. Any changes that would effect both should likely be done in the parent repository.
With this in mind I would only recommend forking your own repository where the repositories are suitably different enough to justify the new repository not just being a branch (in my case it was having a completely different technology rendering my data).
Conclusion
I am delighted with how easy this is to do. I was able to easily build my React project in such a way that I can keep it up-to-date with it’s parent project. This process would also seem to lend itself to building out several different flavors of the original repository. What if I wanted to have one with Angular? Or Vue? Or whatever other front-end framework is hot two weeks from now? Make the repository, follow the above steps, and you’re on your way.