Should collaborators on a private Github repository each fork the repo?

Question

I'm working on a project at the moment, and we have the source code up in a private repository on Github, with each of us as a collaborator.

What we are unclear on is how to separate each of our work.

What I think we need to do is:

1. Each of us needs to fork the repository
2. When we are ready to push our code, we then submit a pull request to the project leader's repo, who can at the same time use this as an opportunity to do a code review

When it comes to private repositories, is this what forking is supposed to be used for, or am I overcomplicating the situation?

Answer 1

Cloning the repo to the developer's local machine is already a kind of forking. If each developer forks the repo on GitHub, this only serves to publish their current state of work.

This can be appropriate when there is a central master repo, and many contributors that are not trusted with direct access to that repo. This works great for open-source projects where everyone can contribute and issue a pull request that is then reviewed and merged by a group of core maintainers. Using multiple repos enforces a pull-request based workflow.

In a small, trusted team, this is not necessary. To prevent different people getting in each others way, a strategy such as the Git Flow can be followed: Each small feature is implemented on a separate feature branch. When the feature is complete, it is merged into the master branch. Most teams will couple this with a pull request or code review by convention, but are trusted enough to skip that if appropriate. Whereas separate repos would lead to a developer publishing their current state on their forked but team-visible repos, in a single common repo they would push their changes to a separate feature branch. Doing all development on master/trunk is highly discouraged in most workflows.

The difference ends up being solely about access management, and not so much about the implemented workflow. You can do pull-request based workflows with either setup. From a raw Git perspective, there's not much difference between a fork and a branch – either approach essentially shares the history of the project and allows commits to be added without affecting other branches/forks. Considering this, it would be much better to share a single repo when in a trusted, closed group.

Answer 2

This would work, or you could use a branching method where each contrib has their own branch(es), that when the team agrees, are merged with master.