This example will help illustrate the standards and best practices of working on GIT Forked Branch.

Git – How to work on Forked Branch

Let’s consider the scenario like, John is developing a new feature in the Car application that allows cars to honk. Sally is the ops engineer who will be responsible for releasing the code changes on May 10th, 2021. The repository is named after the application (Car).

Step 1: Fork the repository

First, John needs to go to the team’s organization in Github since he has never worked on the Car project before. Once he finds the project, he will click the Fork button to copy that repository to his own user’s account.

Step 2: Check out the repository

To work on code, he will need to checkout or clone the repository to his computer. We’ll assume he’s using Linux. The URL to use to clone the repository can be found on his forked copy of the project in Github.

$ git clone git@github.com:john1234/Car.git

This will clone the repository to his local disk. The local repository will be set to track his repository on Github, and the link to his forked copy on Github is called origin. He will also need to track changes from the upstream repository he initially forked from, so he’ll need to add that link, or remote, as well.

$ git remote add upstream git@github.com:chandra-goka/Car.git

This will create another remote link to a repository we’ll name upstream.

Step 3: Make a feature branch

John follows the best practices of this guide and creates a feature branch for his changes.

$ git checkout development
$ git checkout -b honk-feature

Step 4: Develop

John then develops his changes to the application to implement the honking functionality to the Car application. He makes several commits along the way, for example:

$ git add .
$ git commit -m "Added button stub to initiate a honk."

Step 5: Update against upstream

Before John merges his changes into upstream, it is important he download any changes made to the upstream branch before creating the pull request. He will also rebase to avoid unnecessary merge commits in the pull request.

$ git fetch upstream
$ git rebase upstream/development
$ git push -u --force origin honk-feature

Step 6: Create pull request

To get his changes accepted to the upstream repository, John goes to the Car project in his account in Github, and accesses the pull request feature. He makes sure to set the source for the pull request to his forked repository and his feature branch, and the destination to the upstream repository and the development branch. He types a descriptive title along with a list of changes in the description of the pull request. Once the pull request is created, he copies the URL of the pull request and emails the team list notifying the rest of the team that a pull request exists, and what the changes in the pull request are.

Step 7: Pull request is accepted

Another team member, Chris, sees the pull request and reviews it. He finds the changes acceptable and merges the pull request.

Step 8: Release the changes

John creates a release pull request from the upstream’s development branch into the master branch. He names the title as “2021 May 10 – Scheduled Release”, and links the release page on the wiki in the pull request’s description. On 5/10/2021, Sally pulls the pull request and deploys the application.

References:

Happy Learning 🙂