Two Github Workflows

How to use Git for collaboration between multiple developers?

Github provides two main collaboration workflows for software developers. As each developer has set up a GitHub account (free), you can:

  1. Add the developers as collaborators (from the settings menu) to the main repository which will allow them to push their changes.  Or, 

  2. Let the developers fork the repository and issue pull requests to integrate changes.

The first option "Adding Collaborators" is preferable if a team of trusted developers (your team) is making or maintaining a software product. There is a single repository for the project on Github and each developer will have a local repository for their development work.

The second option, "The forking " is useful if there are external teams or freelance developers using their own version of your product. It allows them a way to offer their changes back  (via pull requests) to enhance your product. Each fork is generally considered as a distinct viable variant of your project.

In general, Forking is also been useful in an open-source environment while you are 'coming to trust' a potential collaborator. If you find yourself routinely accepting their pull requests, you may 'promote' them to being a collaborator.


Branches are important and very useful. It's hard to do without them on the remote repo if more than one developer needs to work together on an experimental feature or significant extension to your project.

Note that every git checkout is a repository, so in some trivial sense every developer must indeed have their own repository.  It is quite possible to only have one "shared" repository on GitHub, either with multiple keys, or one key.  This requires more coördination upfront -- you have to agree on where the development is headed.  With multiple "public" repositories, you can delay this.  People can look at each other's work and discuss whether it should get merged into a blessed repository. You can also do this with multiple branches on one repository, and you can also do discussions via sending around patch sets, it's just a matter of what's easier

Forking vs Cloning

Forking is done on the GitHub Account while Cloning is done using Git.

  • When you fork a repository, you create a copy of the original repository (upstream repository) but the repository remains on your GitHub account.

  • Whereas, when you clone a repository, the repository is copied onto your local machine with the help of Git.

Changes made to the forked repository can be merged with the original repository via a Pull request which informs the repository owner that we there are some changes and asks him to merge.

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 for the repository otherwise this is not possible. If the user does not have the 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).