Reputation: 1625
I want to fork a github project to fix a couple of issues and then send a pull request.
The problem I'm running into is that I've already forked the project to adapt it for another user base.
Is it possible to create a second fork? If so, how?
When I try to fork now it just takes me to the previously created fork.
Upvotes: 61
Views: 22522
Reputation: 31686
The trick is not to use the master
branch to create pull requests. Then you won't need to create multiple forks since you can make as many branches as you need and make pull requests against each branch independently.
Given a forked repo with a clean master
(or e.g main
) branch, create a dedicated branch and use that branch to make your pull request.
If you prefer, you can also create branches directly from the web UI (although it might not be obvious).
Click the branch selection dropdown, type the new branch name in the input field, and then you'll see a clickable link Create branch: <new-branch-name>
as shown below. The tricky UI part is that it might not be obvious you should click the "create branch: xyz..." — it is NOT displayed as a button or as a hyperlink, and it's not obvious that this is a clickable link. Anyone probably assumes that the search box is for searching branches, and not for creating them. Given that it appears as a search field people would probably ignore the placeholder which says 🔍 Find or create a branch... purely because of visual cognitive dissonance.
In case you already made changes directly in your fork's master
branch then consider moving those changes to a dedicated branch (e.g. git checkout -b bugfix42
) and then hard resetting the master
branch to the original remote so that you can keep it clean for synching with the upstream repo.
See also:
Upvotes: 9
Reputation: 2406
As others mentioned, you can not have two forks of the same project under the same account.
You can create a github organization.
Then, when you fork, you can assign the fork to your organization.
Upvotes: 3
Reputation: 41
You can easily accomplish your purpose by using the concept of multiple remotes.
Within your repository execute the following sequence of commands:
git remote add upstream https://github.com/user_or_org_of_upstream_repo/upstream_repo
git fetch upstream
git checkout upstream/main
git checkout -b name_of_branch_you_want_to_track_in_your_repo
Make, add, and commit your edits, then push the changes to your branch back into your GitHub fork with:
git push --set-upstream origin name_of_branch_you_want_to_track_in_your_repo
The branch, completely disconnected from the other branches in your repo (other than any source tree parentage as far up the line as the most recent common ancestor), will now be available to use for a pull request in GitHub.
Voila!
git remote add upstream https://github.com/user_or_org_of_upstream_repo/upstream_repo
adds another remote repository and labels it upstream
. The label could be anything -- upstream
is more or less the accepted standard name for the parent of your fork, but it could be 'bob', 'mary', 'dirt', or anything else. Also, the remote can be any repository at all, though I've only ever experimented with fetching from a repository that is at least a parallel fork of the same upstream remote.
git fetch upstream
Does the work of actually getting the main and other branches of the new repository and cloning them into your local. They are just sitting there now, waiting for you to do something with them.
git checkout upstream/main
Checks out the main branch of the repository you have labelled in your remotes list as 'upstream'. Of course, you could check out any other branch in the repository.
git checkout -b name_of_branch_you_want_to_track_in_your_repo
Creates a local branch where your changes can be tracked.
git push --set-upstream origin name_of_branch_you_want_to_track_in_your_repo
pushes your new branch back to the default remote, origin
. Again, you could push the branch to any other remote for which you have write permissions.
When you fork and clone your repository, the default remote repository is your fork and the label for the fork is 'origin'. The git remote
command shows this -- for example this is the output of that command for a fun little repo I made to [unsuccessfully] master the online game 'Wordle'.
> git remote -v
origin https://github.com/jameshalgren/wordle_analyst_ideas (fetch)
origin https://github.com/jameshalgren/wordle_analyst_ideas (push)
As you work with your fork, the branches in your local repository will likely be based on the main branch within the origin repository. When you add/commit/push changes to your branches, the remote version of those same branches will be updated in your fork on GitHub. That's why you see this message the first time you try to push a new branch:
fatal: The current branch test_new_branch has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin test_new_branch
Notice the label 'origin' in the instructions. This is a hint to the power of remotes. You can actually push to any other remote repository, as long as you have appropriate permissions. In the first command, git remote
, you can also see the origin
label. If you forked the repository in the example above, added remote repositories for your upstream and possibly several other collaborators, the git remote
command would start to look like this:
> git remote -v
origin https://github.com/youruser/wordle_analyst_ideas (fetch)
origin https://github.com/youruser/wordle_analyst_ideas (push)
upstream https://github.com/jameshalgren/wordle_analyst_ideas (fetch)
upstream https://github.com/jameshalgren/wordle_analyst_ideas (push)
collaborator https://github.com/collaboratoruser/wordle_analyst_ideas (fetch)
collaborator https://github.com/collaboratoruser/wordle_analyst_ideas (push)
Upvotes: 4
Reputation: 3765
The best way, recommended by github manual, is use command line git, mirror clone your repo and push it to your github.
If you strongly prefer GitHub web interface to the command line, a GUI friendly workaround is create a new organization and fork to that new organization.
Another GUI way I can think of is to declare a fork as a template repo using repo's setting so you can create as many forks as you need.
Upvotes: 4
Reputation: 1625
There is no way to have two forks of the same GitHub project unless you use two different GitHub accounts.
So:
Create a separate GitHub account (and verify the email)
Fork the project
Invite your main GitHub account as a "Collaborator" (from the settings)
You may need to add the extra step of creating an organization with the new GitHub account and inviting your main github account as an owner of the organization (also make sure your new fork is in that new organization). This will let you do things like deploy automatically to a Heroku app that is connected to your main GitHub account.
Why can't we just have multiple forks???
Upvotes: 23
Reputation: 136958
I mean that I could just commit and push without making a pull request, but I want to do it the offical way and I want somebody else to review the changes before I push to a public project.
GitHub pull requests do not need to be submitted from a fork; they work within a single repository as well:
Pull requests are especially useful in the fork & pull model because they provide a way to notify project maintainers about changes in your fork. However, they're also useful in the shared repository model where they're used to initiate code review and general discussion about a set of changes before being merged into a mainline branch.
There's nothing stopping you from creating a pull request even if you don't technically have to. This is often considered a best practice, and GitHub's own Flow model is largely based on pull requests.
Creating a pull request within a single repository is very similar to creating one from a fork:
Upvotes: 9