Why Did We Opt for Git Forking Model?

Git is an open source project to control versions of your code. It has been very popular among developers community for code collaborations and release managements. I have been introduced with two work flows. One through Branching model and other through Forking model. Here I want to share my experience across both of these models.

At iZAP, we were working with branching model since last 3 years. It was the time when we have team under one roof where we can do code and code reviews in controlled manner. But when we start expanding out of our office while collaborating with other developers. That time we have to have something better where we can have better control over code merges. So that’s where we were introduced with Forking Model.

Git Branching Model: Branching is a model to handle the code changes within the single repository in order to merge the code with other code changes.

"Git branching model"

In this model, One main repository also known as origin is placed at the remote git server. This repository is the central repository for all code collaboration. All developers who are contributors to this repository can pull and push to this remote repository.The developers create the local repository on their machine,commits and push the code to the remote repository. In this flow, the code separation is handled by concept of branch. where a branch is a lightweight movable pointer to the sequence of commits objects.

Git Forking Model: Forking is a model to have a copy of a server repository on the server side itself under different owner and this maintains the code merges by making use of two repositories. This is a concept from github and not from git. The concept behind this is to copy the repository to your own account. And workflow changes as compared to branching model.

"Git forking model"

In this model, there are two kind of remote repositories. One as upstream and other as origin. The upstream is the top level repository. This repository is owned by the project maintainer. The origin repository is also placed at remote but owned by the working developers. This repository is forked from the upstream. The developers can only pull and push to their own repository that is their own personal origin repository. No one can push the code directly to the upstream. They create a pull request to the upstream, and upstream repository maintainer on demand pulls the request, review the code and if acceptable then merge code to the upstream repository.

The basic difference between both models is, Authenticated code merges, which will help project managers to review code before it get actually merged in branch. Following are couple of my personal experiences.

In case of Forking model, As no single developer has the direct rights to push the code to the main master repository(aka upstream). So when they trigger pull request, and code reviewer can view the code committed and based on code quality in terms of coding standard or logic, they can accept or reject the pull request. Reject will halt the unstandardised code to be added in the system. So more transparency is there when code merges happens. This idea lies in the core of Open source development, where the whole community contribute to the software developments.

In Forking model, The code separation layer lies at the repository level, But in Branching model, the same happens to be at branch level.

In Forking model, For developing the code, the developer need not to be the contributor of the project. They can notify their changes to the project managers with their pull requests. So this model gives more independence to developers to work without any upfront coordination at least for all open source projects. Where as Branching model, An authorised developer is responsible to merge his code in the origin branches, So this model gives the developer more freedom to merge their code into the system without any hindrance.

In Forking model, For pulling the in progress code from other developers, You need to pull the code from other developers origin repositories. In Branching model, you just need to pull the common origin branch.

Forking model does very well when development team is quite large. As here, the repository level access can help to categorise the code commit history. So make the project less noisy and messy.

In nutshell, The Forking model is an enhancement of the Branching model with limited access provision to all code contributors. The forking model provides us more control while verifying code standards. Where as the Branching model is quite simpler, But still efficient and fast. Forking model is more suited to the open source projects with the decent number of contributors and Branching model suits more to small projects. More transparency is there when code merges happens in Forking model because of the code pull requests criteria.