Best practices on GitHub repos, to Fork or create a New Branch
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.
6 Solutions collect form web for “Best practices on GitHub repos, to Fork or create a New Branch”
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.
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.
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.
Atlassian has an excellent write up on the differences between forking and other git workflows on their git tutorials page. (See Forking Workflow | Atlassian Git Tutorial)
The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.
It’s important to understand that the notion of an “official” repository in the Forking Workflow is merely a convention. From a technical standpoint, Git doesn’t see any difference between each developer’s public repository and the official one. In fact, the only thing that makes the official repository so official is that it’s the public repository of the project maintainer.
All of these personal public repositories are really just a convenient way to share branches with other developers. Everybody should still be using branches to isolate individual features, just like in the Feature Branch Workflow and the Gitflow Workflow. The only difference is how those branches get shared. In the Forking Workflow, they are pulled into another developer’s local repository, while in the Feature Branch and Gitflow Workflows they are pushed to the official repository.
I would work in a “centralized” way, that is, having a main repo that everyone fork, every developer would commit to their own repo, that makes the code review process easier. Once the code review has been done you can merge the changes to the main repo.
This is just the main idea…
You would also need to set up the strategies on how to branch. I would recommend Nvie model
I feel, the bottleneck is not forking or branching. In both approaches, you need manual intervention of merging / reviewing the changes.,
So the bottleneck is with the application development approach. I see a problem, when a team is collaborating on the same file. With a proper architecture design, can it be split as separate modules with individual files ? On runtime or build time, the separate modules (or files) could be aggregated to form the whole feature (or a single file).
If we could solve it in that level, once the team size increases or the feature complexity increases, things will be smooth to scale.