Forking Repository

Owned by Ayobamii Idowu (Deactivated)
Last updated: Oct 03, 2022 by Jai Dhaliwal (Unlicensed)
3 min read

Forking Repository

A fork is a copy of a repository that you want to make changes to. Instead of using a single Git repository as the "central" codebase, forking a repository gives every developer their Git Repositories. Each contributor has two Git repositories: private local, and public.

The advantage of the forked repository is that contributions can be integrated without needing everybody to push to a single central repository. Developers push to their git repositories, and only the administrator of the original repository can merge the forked repositories. The administrator accepts developers' commits without giving them written access to the official repository.

Note: The options below are suggestions on how Forminator partners can fork CHEFS Repository and manage their forked repository.

First Option:

  1. Create a fork of Chef's repository into the Ministry's Github.Git Branching and Pull Request Workflow

  2. Clone forked repo.

  3. Create a feature|bug fix branch.

    • git checkout -b  feature/<ticket id>-<ticket-title-short>

  4. Push local changes to remote feature|bug branch.

    • git add

    • git commit -m "your commit message here"

    • git push

  5. When ready, create PR to merge changes from the feature|bug branch to the master of the forked repo.

  6. Create PR from the Forked branch to the main Chef Repository master branch.

Second Option:

  1. Create a fork of Chef's repository into the individual developer's Github.

  2. Create a feature|bug fix branch.

    • git checkout -b  feature/<ticket id>-<ticket-title-short>

  3. Before pushing local changes, update local changes with the remote features branch.

    • git pull origin features

  4. Push or publish local changes to feature|bug fix branch.

    • git add .

    • git commit -m "your commit message here"

    • git push

  5. When ready, create PR to merge changes from the feature|bug branch to the CHEFS Repository features branch.

  6. Before creating PR from the feature branch, update it with the master branch.

    • git fetch origin features

    • git switch features

    • git pull origin

  7. Create PR from the feature branch to the main Chef Repository master branch.

Third Option

  1. Create a fork of Chef's repository into the individual developer's Github.

  2. Create a feature|bug fix branch.

    • git checkout -b  feature/<ticket id>-<ticket-title-short>

  3. Before pushing/publishing the feature|bug branch to remote, update it with the master branch.

    • git pull origin

  4. Push or publish local changes to feature|bug fix branch.

    • git add .

    • git commit -m "your commit message here"

    • git push

  5. Create PR from the feature branch to the main Chef Repository master branch.

Creating and Merging Pull Requests from partners

  1. Create a PR from the forked CHEFS Repository to the CHEFS master branch. Check out a more detailed guide on creating from a forked repository https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork0

  2. The PR will be automatically deployed to PR Environment in the Openshift and will start test automation. Note: the forminators team will not review the code until the automated test is passed.

  3. Request code review from the partners. Access will be given to UI/UX designers, product owners, and other stakeholders to review the change
    Two scenarios can make the forminators team lead to reverting the changes:

    1. If designers are not satisfied with the UI and want improvements to be implemented by the partner developers

    2. If the forminators team product owner declines the change. It is believed there would have been high-level conversations between the product owners which should make this scenario happen less often

  4. Once the change is approved by the product owner and UI/UX designers, the forminators team developers will begin technical review.

  5. The code review process will continue until the PR

    1. is approved after all requirements are satisfied.

    2. is declined if the reviewers think the work is not ready for a pull request

  6. If the PR is approved, it will be merged into the master branch of the CHEFS Repository

  7. The change will automatically deploy to the dev environment after merging the PR to the master branch.

  8. Once approved, the forminators team lead will deploy the change to the test environment, where further smoke or sanity checks will be done.

  9. Once the feature is ready for production, the forminators team lead will deploy it to the production environment.

Â