Git rules

In this section, we collected a handful of Git rules developers should stick with. Please make sure to follow rules below while working with Git.

Branch naming

Mostly a Pull Request has a related Jira ticket so the branch name have to consist of Jira ticket's id, for example ATLAS-XX. If you work on preparing Pull Request for upcoming release the branch name should look like release-vX.Y.Z where X.Y.Z reflects to the version of a package you are going to release. In other cases it's up to you how to name your branch.

Commit linting

To make sure a commit message follows conventional commits specification and to run eslint commands on @adjust/components and @atlas/atlas-documentation workspaces we use Husky package.

On the GitHub side unit-tests, visual-regression-tests and linting workflows are triggered once you pushed your commits.

Git workflow

In order to preserve complete history and chronological order Atlas design system team agreed to use merging instead of rebasing. Please do git merge not git rebase while working with branches.

Reviewing a Pull Request

The more reviewers from Atlas design system team you add in your Pull Request the better. Usually to get a green light for merging a Pull Request into master branch you have to get at least two approvals from an Atlas member.