Menu
The term fork (in programming) derives from an Unix system call that creates a copy of an existing process. So, unlike a branch, a fork is independent from the original repository. If the original repository is deleted, the fork remains. If you fork a repository, you get that repository and all of its branches.
Forks are best used: when the intent of the 'split' is to create a logically independent project, which may never reunite with its parent. Branches are best used: when they are created as temporary places to work through a feature, with the intent to merge the branch with the origin.
In github (and in git's mental framework) you clone and fork repositories. There's no way to fork a branch; that doesn't make sense. Just fork the project, and work off the branch you're interested in. You don't lose anything by doing so.
A fork is a copy of a repository that you manage. Forks let you make changes to a project without affecting the original repository. You can fetch updates from or submit changes to the original repository with pull requests.
Think of it this way:
The repo[sitory] corresponds to the collaborated work of the team across one or many branches. All contributors have their own copy of it.
Each fork of the main repo corresponds to a contributor's work. A fork is really a Github (not Git) construct to store a clone of the repo in your user account. As a clone, it will contain all the branches in the main repo at the time you made the fork.
Each branch within the fork and/or in the main repo can correspond to several kinds of things, depending on how you want to work. Each branch could refer to a version of the project but can also correspond to different channels of development, like hotfixes or experimental work.
The pull request (in the GitHub ecosystem) corresponds to the task. Every time I want to contribute an isolated finished task to the main repo, I create a pull request corresponding to the commits made in that task. These commits are pulled from either my fork or my branch to the main repo.
A commit is a set of changes to the code. This is one of the most interesting things about Git. You don't transfer files, you transfer logs of changes.
All branches on GitHub will be copied in a fork. (Obviously, this doesn’t include branches that were never pushed to GitHub in the first place.)
But a fork is a GitHub-to-GitHub operation; nothing is copied to your PC. It’s not quite the same as a Git clone. If you mean to ask “what’s copied when I clone a project?”, see the manual for git-clone(1).
Fork is a clone on the GitHub side (it clones everything).
When you are cloning a repo, you are getting the all history of said repo, with all its branches.
Even though you can in theory change the default branch of a remote repo, a clone from a GitHub repo mainly look for the master branch. Meaning to change the "default" branch a GitHub clone will get, you need to rename the master branch.
If you fork a project, you are making a copy of the whole project to your git hub account. you are not coping anything to your PC
To make a copy in your PC you have to clone it and pull all the stuff and you will got all branches & code of that project
If you create a fork of a project from the Github website, you get all the branches from the upstream project.
If you clone from your newly minted fork to your local PC, you will have the origin remote on your PC pointing to the master branch of your fork on Github.
This can be explained very well. You have a central repository at GitHub. Whenever you take a clone of it on your personal computer to do some changes, this local clone of the main repository is called a fork.
The branch is something different and is included in the fork/repo. Actually the branch is your work at different stage of development. They are created as and when required to save a set of functionalities, to give access to different users, to demonstrate the site to client, etc.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With