Opensaucery Version Control Flow

[opensaucerer]

A few things to note to an excellent work week in regards to how we handle version control here at Opensaucery.

• When working on anything new, create an issue for it, if one has not been created before.
• Let the issue have the title and description of what you're working on such that it is easily understandable by anyone.
  Then create a feature branch from the issue by clicking on the Create a branch button on the issue page, see this video for a sample illustration.
• Using the branch name, from above, create a checkout branch from the development branch (not the main branch) as shown in the video and do all of your work on that branch in relation to the issue you're solving.
• Note importantly that your commit messages should be descriptive and follow the semantic commit message format.
• When done, don't create a PR without first pulling the development branch into your current branch git pull origin development --rebase=false
• We don't do rebases here, contrary to what others might suggest, we think it's easier and simpler for engineers to handle conflicts in a merge than in a rebase.
• Once you have all the above done, you can proceed to create a PR against the development branch.
• Let your PR have a title and description of what was done and what anyone should be on the look out for. For example, if you did something in a particular way and you think someone might not easily get it, you can save them the review time by indicating it in your description so it becomes clear why you did it that way.
• Don't forget to link your issue to the PR by adding the following into the description Closes <link to the issue> or Fixes <link to the issue>
• Then tag the necessary team as reviewers of the PR. Either the backend-engineers or frontend-engineers or mobile-engineers or cloud-engineers or just opensaucerer if the option to tag a team is not available.
• Now, copy the link to your PR and head over to Slack and share it in the be-pull-request or fe-pull-request or cloud-pull-request or mobile-pull-request channel as necessary. Don't forget to tag @channel so everyone in the channel is notified to review it.
• Once that is done, wait a few hours, say 5 hours, and try to follow up again every 5 hours till your PR gets merged.
• Once your PR is merged to development, sync with the necessary team and test as required, and if there's no team to sync with, run the test yourself on development and ensure your feature works as expected and all edge cases are caught.
• Next, if what you're working on has a corresponding FE issue, then sync with the required FE engineer to get the feature integrated on the frontend. An issue is not complete until everything that relates to it is fully done.
• Ensure that you are aware of the lifecycle of the FE integration as well till it gets merged into development and tested as necessary.
• Once both FE and BE have been moved into development, you both can then be sure that your work is done and you can then wait till the next production release cycle is due and the cloud-engineers team makes the release branch for features that need to go into production.
• However, if what you've worked on is a hotfix for a bug and needs to go in urgently, then please, don't wait for a production release cycle as that is not necessary. Instead, open a PR from your feature branch to the main and share it in the necessary channel again and follow up as well till that gets merged.
• Now that your feature or fix is in production, you can't relax yet. Test again on production using the production credentials that can be found in the credentials channel and ensure all work well.
• If all is good, then it's time to relax while you await your next task or you can check the backlog and find something interesting you'll like to work on. We're open and surely willing to spend resources on any idea that can positively influence the organization.