Best practices on GitHub repos, to Fork or create a New Branch

Question

I'm looking for the best practice, forking vs branching on GitHub. I've read this Forking vs. Branching in GitHub, but it's not relevant.

Our team of 5 people are working on the same repository, and we would like to avoid merging problems, conflicts or regression in the code. The goal is for the 5 persons to work on different parts of the project, often on the same file.

I would like to know if it's worth it to :

• fork the project, work and create pull requests, so each persons can review the code easily, or
• create a new branch - work and merge on master when work is done.

Answer 1

To me, the best practice when dealing with a project with more than one developer, is to use gitflow branching model.

First, the master branch will now only be used to keep track of the releases of your app, major, minor or patch versions, following the Semantic Versionning.

The develop branch will be the core of your project, since it will make the bridge between the different features and your releases.

This system helps to reduce the number of merge, just as a simple branching system will do, but add the semantic logic, and the friendly and simple commands that comes with it.

For more info about gitflow you can follow this link.

Answer 2

Maintaining forks introduces additional overhead as each fork needs to pull changes from upstream. I see no benefit to doing so when every developer can have access to a shared repository.

Pull requests can be a very useful mechanism for code reviews but they do not demand that you use forks. You can create branches in the same repository and use pull requests to manage merging them into your master branch.

Answer 3

At my office we have a similar situation: a large project where five or more developers have commit access, and typically at least three are working on it at any time. We manage everything using a single repository with branches and pull requests, and we haven't had any issues (that were caused by our source control setup, anyway).

Pull requests are an excellent way to solicit code reviews from other developers, which is especially important when those same developers may be working with your code the next day. Forking, on the other hand, doesn't really provide any benefit; it is a solution to the problem of allowing broader access to a controlled codebase, and that problem just doesn't exist when everyone has commit access to the repo.