Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Forking Repository

...

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 formilators 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 workflowBranching 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.

...

  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.

...

  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.

...

  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 Forminators team developers.

  4. The code review process will continue until the PR

    • is approved after all requirements are satisfied.

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

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

  6. The forminators dev team lead will deploy the merged PR from the master branch to the Development environment.

  7. In the development environment, access 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.

    If
  8. Once the change is approved by the product owner and designers approve the changes, then UI/UX designers, the forminators team developers will begin technical review.

  9. 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

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

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

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

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

 

...

  1. .