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 formilators partners can fork CHEFS Repository and manage their forked repository.
First Option:
Create a fork of Chef's repository into the Ministry's Github.Git branching and pull request workflow
Clone forked repo.
Create a feature|bug fix branch.
git checkout -b feature/<ticket id>-<ticket-title-short>
Push local changes to remote feature|bug branch.
git add
git commit -m "your commit message here"
git push
When ready, create PR to merge changes from the feature|bug branch to the master of the forked repo.
Create PR from the Forked branch to the main Chef Repository master branch.
Second Option:
Create a fork of Chef's repository into the individual developer's Github.
Create a feature|bug fix branch.
git checkout -b feature/<ticket id>-<ticket-title-short>
Before pushing local changes, update local changes with the remote features branch.
git pull origin features
Push or publish local changes to feature|bug fix branch.
git add .
git commit -m "your commit message here"
git push
When ready, create PR to merge changes from the feature|bug branch to the CHEFS Repository features branch.
Before creating PR from the feature branch, update it with the master branch.
git fetch origin features
git switch features
git pull origin
Create PR from the feature branch to the main Chef Repository master branch.
Third Option
Create a fork of Chef's repository into the individual developer's Github.
Create a feature|bug fix branch.
git checkout -b feature/<ticket id>-<ticket-title-short>
Before pushing/publishing the feature|bug branch to remote, update it with the master branch.
git pull origin
Push or publish local changes to feature|bug fix branch.
git add .
git commit -m "your commit message here"
git push
Create PR from the feature branch to the main Chef Repository master branch.
Creating and Merging Pull Requests from partners
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
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.
Request code review from the Forminators team developers.
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.
If the PR is approved, it will be merged into the master branch of the CHEFS Repository.
The forminators dev team lead will deploy the merged PR from the master branch to the Development environment.
In the development environment, 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:
If designers are not satisfied with the UI and want improvements to be implemented by the partner developers.
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 the product owner and designers approve the changes, then forminators team lead will deploy the change to the test environment, where further smoke or sanity check will be done.
Once the feature is ready for production, forminators team lead will deploy it to the production environment.
8.