Branching
In this guide, we explore the essence of Git branches, their role in managing project iterations, and how they facilitate parallel development workflows. From creating feature branches to merging changes, you will gain a solid understanding of how Git branches streamline the development process.
Test Branches
When you commit to the FOO-123_some-very-important-feature branch, the GitLab CI/CD pipeline will automatically deploy the latest version of that branch to test-foo.cloudsuite.com. This allows you to test your changes before merging them into the develop branch.
Develop
The latest version of develop is deployed to test-foo.cloudsuite.com when a Merge Request is closed on develop.
When you close a Merge Request on the develop branch, the GitLab CI/CD pipeline will automatically deploy the latest version of the theme to test-foo.cloudsuite.com. This allows you to test the changes before merging them into the master branch and deploying them to production.
Master
When the develop branch is merged into master, the GitLab CI/CD pipeline can be configured to trigger two manual pipelines: one to deploy to acceptance and one to deploy to production.
This means that after the merge, you will need to manually start two pipelines, one for each environment. These pipelines will be responsible for deploying the latest version of the theme to the respective environments.
To start the manual pipelines, go to the Pipelines page in GitLab and click the Run pipeline button next to the corresponding pipeline.
Once the pipelines have started, they will run through the necessary steps to deploy the theme to the respective environments. This may include building the theme, running tests, and deploying the theme to the production server(s).
Once the pipelines have completed, the theme will be deployed to the acceptance and production environments.
This process allows you to review the changes before deploying them to production and to back out of the deployment if something goes wrong. It helps ensure that your deployments are controlled and predictable.
Guidelines / Instructions
How to Create Branches
| Type | Convention | Explanation |
|---|---|---|
| Branch (feature) | {TICKETNUMBER-000}_{short-description-divided-by-dashes} | A branch name should always be named according to this convention; this way, Jira can retrieve the branch/commit data from GitLab to implement the Jira flow. CSUX-123_header-implementation |
| Sentry fix | SENTRY-{sentry key} | Sometimes, a Sentry issue needs to be fixed without a Front-end ticket. Example: SENTRY-62710 |
Commits
Commits should always have a descriptive message; a short message describing what kind of changes this commit includes.
Example:
git commit -m "Change the version of slick-slider to improve performance"
Even better: Start your commit with the ticket number to create a nicer overview in the Git log.
Example:
git commit -m "CSUX-123: Change the version of slick-slider to improve performance"
:::
Do not use commits like update, test, do it, etc., as this is not descriptive and makes it very hard to understand what is included in the commit.
Best Practices
- Keep your commits as small as possible to be able to easily revert your changes in case something goes wrong.
- Before you merge your branch, make sure 'Delete source branch' is checked.