How we work: Branching strategy

Development flow

1. Create a feature branch using main as the base branch

   1. git checkout -b fer/1234
   2. Our feature branch naming convention is an abbreviation of the author's name / the issue number. For example fer/1234

2. Create a Pull Request

   1. git push origin fer/1234
   2. Open GitHub and create a new pull request
   3. Team convention for title: gitmoji issue title or good description #issue number
   4. Connect Github issue in the created PR after creation

3. Move the issue to the Technical Review column in the Kanban board

   1. Wait for a code review from one of the team members
   2. Iterate your code until it is tech-approved ✅

4. Deploy your changes to staging

   1. In your local environment, checkout the staging branch and pull the latest changes
      1. git checkout staging && git pull origin staging
   2. Squash and Merge your feature branch to the staging branch
      1. git merge fer/1234
   3. Push the changes directly to staging. No pull request is required.
      1. git push origin staging
   4. Deployment to the staging environment will be triggered automatically

5. Move the issue to the Acceptance Criteria column in the Kanban board (if the issue can be reviewed externally)

   1. Wait for external review
   2. If external review is APPROVED ✅
      1. Squash and Merge the Pull Request to the main branch
      2. Deployment to pre-prod environment will be triggered automatically
   3. If external review is NOT APPROVED ❌
      1. Go back to step 3.2. (Iterate your code until it is tech-approved)

6. Move the issue to the Deploy column in the Kanban board, and add the "Ready to Deploy" label

Deploying to production

1. Run the deploy all websites/studios to prod script through GitHub Actions

   1. Create a Release log in GitHub discussions
   2. Post the release log link in the #envis Slack channel

2. Close issues with the label "Ready to Deploy"