Github what is forking

This allows the project owners to control changes within their codebase. The forking step creates a copy to which you do have permission to commit and branch on and you can consider this your working copy of the project. You can make changes and commits here, safe in the knowledge that you will not affect the main repository.

The process of forking on GitHub is very simple. Make sure you are logged into your account on GitHub and then open the project you are interested in contributing to. Click on this button to begin the automatic forking process. Now that you have your fork, the next step is to clone the code down to your local development machine. Again, GitHub make this quite simple in their UI.

To clone a repository you will need its URL. A button to the right hand side of the URL allows you to copy it into your clipboard.

There are various graphical tools you can use to work with Git repositories but for simple procedures, the command line is often fastest. You will see the output of the clone command as it clones the contents of your repository onto your local device. Once the command completes you will have a new folder containing the cloned repository. If you've made a change that you feel would benefit the community as a whole, you should definitely consider contributing back.

To do so, head on over to the repository on GitHub where your project lives. You'll see a banner indicating that your branch is one commit ahead of octocat:main.

Click Contribute and then Open a pull request. Click Create pull request. GitHub will bring you to a page where you can enter a title and a description of your changes. It's important to provide as much useful information and a rationale for why you're making this pull request in the first place.

The project owner needs to be able to determine whether your change is as useful to everyone as you think it is. Finally, click Create pull request. Pull Requests are an area for discussion.

In this case, the Octocat is very busy, and probably won't merge your changes. For other projects, don't be offended if the project owner rejects your pull request, or asks for more information on why it's been made. It may even be that the project owner chooses not to merge your pull request, and that's totally okay. Your copy will exist in infamy on the Internet.

And who knows--maybe someone you've never met will find your changes much more valuable than the original project. You've successfully forked and contributed back to a repository.

Go forth, and contribute some more! Git Cloning and Git Forking. This tutorial will help you understand:. Changes made to the forked repository can be merged with the original repository via a pull request.

Pull request knocks the repository owner and tells that " I have made some changes, please merge these changes to your repository if you like it ". On the other hand, changes made on the local machine cloned repository can be pushed to the upstream repository directly. For this, the user must have the write access to the repository otherwise this is not possible. If the user does not have write access, the only way to go is through the forked request.

So in that case, the changes made in the cloned repository are first pushed to the forked repository and then a pull request is created. It is a better option to fork before clone if the user is not declared as a contributor and it is a third-party repository not of the organization. Forking is a concept while cloning is a process. Forking is just containing a separate copy of the repository and there is no command involved. Cloning is done through the command ' git clone ' and it is a process of receiving all the code files to the local machine.

Forking a Repository is a five steps process but three steps are exactly the same as cloning. Please check docs. Given some of the feedback in the thread I will take a stab at adding a bit more flavor in a few areas. Each VCS provider can create their own definition of what is a fork and what specifically they do for you when you click the magic button or use the API.

The reality is that you are doing a git clone however you are updating the configuration so that you have a distinct location that is a copy of the repository. You can then choose when working with your local repository through the use of remotes to decide if you are interacting with your copy or the upstream. When you locally clone a repository you will automatically have the server setup your initial remote for you. Pull requests are a native git feature these days though they are realistically little more than a message with a patch file that is submitted to the remote specified.

Git is a series of pointers of data rather than just storing the data. If you are interested I have a more lengthy post here Why is it that Pull Requests and Issues share the same numbering sequence on GitHub? As an open source maintainer I often help folks with stale pull requests where they need to integrate changes in the project that does not exist in their fork.

Just want to add that a fork is not really a copy of a repository so far as I can tell , it is in fact just a set of branches into the same repository. If two users fork a repo, then the fork operation creates a set of branches for each user and points these at the same commits as the actual branches.

Now a branch name must be unique within a repo, so I suspect that the fork branches are actually named something like username. Every time you push commits to your fork you are actually pushing them to the main repo! But the main repo never exposes the per-user branches, they simply get filtered out so any commits in these branches are invisible unless you are looking at it via the fork.

So think of a fork as a virtual repository , just a set of branches in the main repository.