Git workflow

In order to ensure a proper tracking and monitoring of the progress, we want to establish some workflows for the git usage (commits, branches, pull-requests, merging, testing).

We use 3 branches:

• dev
  • dev branch
  • Not deployed on any environment
  • Used to for internal testing at Rocket Minds
• preview
  • preview branch
  • Deployed on https://preview.business.booking.com/
  • Used to for internal testing at Rocket Minds
• production
  • master branch
  • Deployed on https://business.booking.com/
  • Used to for internal testing at Rocket Minds

We need to follow a naming structure for the commits and branches

#455-menu-multilingual-styles-update - where 455 is the issue number and followed up by a extensive description of what the fix was.

In most cases - each task will be done in a separate feature branch. In some cases, a feature branch can contain multiple smaller tasks that are somehow related to each other, in this case the title will display the number of each task and a generic name

• feature-455-menu-multilingual-styles-update - where 455 is the issue number and followed up by an extensive description of what the fix was.
• feature-455-456-457-styles-update - where 455,456,457 are the issue numbers and followed up by a generic description of what the fix was.

Not to do:

• Dont use namings like fix, fix #234, #324

Also, we will use for feature branches 3 types of feature codes:

• hotfix (to be started from master)
• fix (to be started from dev)
• feature (to be started from dev)

Release branches will group feature branches that can be tested. Dev branch will not be used for deployment anymore to the dev environment.
Release branches will be deployed to the dev environment from now on.

Feature branches are started by default from the dev branch

1. A new release branch is created (incrementally, for example: 1.1)
2. A PR is opened from the feature branch to the release branch (1.1)
3. The PR needs to be approved by another developer
4. Manually the release branch is deployed to dev environment
5. A PR is opened from the release branch into preview and assigned @danrminds
6. @danrminds tests the feature on dev environment and approves the PR by merging it into preview

7. Deployment on preview of the preview branch contents
8. @danrminds opens a pull-request from the release branch into master and assigns @jerry-booking
9. @jerry-booking tests the feature and approves the pull-request if all ok. If not - leaves comments in the issue or the pull-request
10. Manual Deployment of master branch on production
11. PR from Master to Dev
12. Issue gets closed

If a new feature is dependent on a feature in a release which is not yet merged - the feature branch should start FROM that release branch