Git Forking Workflow

The Git Forking Workflow is a widely used collaboration strategy in open-source projects. It allows multiple developers to contribute to a project without directly affecting the main branch. Instead of cloning the central repository directly, developers create a “fork” of the repository, work on it independently, and then submit their changes through pull requests.

Steps

Each contributor forks the repository, works on their own local copy, and then submits pull requests to the original repository. The general steps in the Git Forking Workflow are as follows:

Fork the Repository

Each contributor forks the central repository to create a personal copy of the project under their GitHub account.
This action creates a completely separate copy of the repository where they have full control.

Clone the Fork

After forking, the contributor clones the repository to their local machine to begin making changes.

$ git clone https://github.com/your-username/repository.git

Create a Feature Branch

It’s a good practice to create a new branch for each feature or bug fix. This keeps the main branch clean and allows for better management of changes.

$ git checkout -b feature-branch

Make Changes Locally

On the new branch, the contributor makes their changes (add features, fix bugs, etc.) in their local repository.

Commit the Changes

Once the work is done, the contributor commits the changes to their local repository.

git add .
git commit -m “Description of changes”

Push the Changes to the Fork

After committing locally, the contributor pushes the changes to their fork on GitHub (or the hosting platform).

git push origin feature-branch

Create a Pull Request (PR)

The contributor then submits a pull request (PR) from their fork (and the feature branch) to the original repository (the “upstream” repository). This is typically done through the platform’s UI (e.g., GitHub, GitLab).
The PR includes the changes made in the feature branch and is ready for review.

Code Review

The project maintainers (or other contributors) review the pull request. They can request changes or approve the PR.
If changes are requested, the contributor can make the necessary adjustments, commit them, and push to the feature branch. The PR is automatically updated.

Merge the Pull Request

After the PR is reviewed and approved, it is merged into the main codebase (usually the main or develop branch).
In some cases, the project may require a maintainer to handle the merging, but it’s common for the contributor to merge their own PR after receiving approval.

Sync the Fork with the Upstream Repository

Over time, the upstream repository may receive updates. To keep the fork up to date with the main project, contributors should sync their fork. This is typically done by adding the original repository as a remote (upstream), and then fetching and merging the latest changes.

$ git remote add upstream https://github.com/original-owner/repository.git
$ git fetch upstream
$ git checkout main
$ git merge upstream/main