Each Git repository containing parts of OMS should comply to these rules:

• The master branch should contain the latest stable release
• The other branches are used for WIP on features and bugs
• One does not push into master directly, it is done via PR
• Before PR is merged into master, it should be reviewed by 2 people other than PR submitter if possible (to double-check)
• The PR to master cannot be merged if CI checks didn't pass
• If the PR is submitted, everything that's inside should also comply to other standardized rules (folder structure, API responses etc.)
• Everybody pushes to the same repository (AEGEE/oms-something) without creating another repo
• Once the PR is merged, the PR branch should be removed to not leave garbage here
• Force-push to development branch is allowed and recommended (to have all the changes in 1 commit and not multiple). Force-push to master, as well as push to master in general, is prohibited.

When working on repositories which include conventional logging, changelog and versioning (currently it's oms-statutory, oms-events, oms-discounts and oms-frontend), the following rules apply:

• after doing the changes and commiting them, bump the version through 'npm version major|minor|patch' (where 'major' is for breaking changes, 'minor' is for new features and 'patch' is for bug fixes and something like that). This will regenerate the changelog, create the tag and bump the version in package.json and package-lock.json
• follow semver (see above for bumping the version)
• follow the conventional commits (see below)
• do not forget to push the created tags to remote repo once you've bumped the version, so other people won't have the changelog generated in the wrong way when bumping the version (as it looks through the tags)
• use merge with commit (otherwise all commits will be squashed into one and all the tags references would be lost, making changelog generation impossible)
• if possible, change merge commit message from "Merge <something> to "chore: merge <something>" to be fully conventional-commits-compliant
• use 1 commit for 1 feature/bug so it'd be easier to understand the project history, not implement two or more features in one commit

The development process

• Developer pulls the latest master and tags list from remote (to have the development branch up-to-date with master)
• Developer creates the development branch
• Developer adds the required changes
• Developer checks if the changes are working properly on the local machine
• Developer commits it using the schema below
• Developer bumps the version (see above)
• Developer pushes the development branch and tags to the repository and creates a pull request to master
• The CI checks pass (if they are failing, such PR cannot be merged and either the PR itself or PR checks should be fixed here)
• The service maintainer + 1 more person look through the PR and reviews it (if there's something wrong, then the reviewers can request changes and ask the submitter to update it)
• The review is passed
• The maintainer merges the PR to master and removes the PR branch
• The person who has the deploy permissions deploys it to production
• Developer checks if the changes on production are working correctly
• Developer closes the Jira ticket

The developer, the reviewer, the service maintainer and the deployer can be 1 person if there are not enough people. Also, if there are not enough people (and only if this is the case) the review can be skipped (though this is not recommended).

Git commit names

Each Git repository should comply with conventional commits idea. The commit names should follow this pattern:

• task(scope): fixed some bugs. Fixes <Jira task code>

As a task, you can use feat (for new features), fix (for bug fixes), chore (for things like version updating), refactor (self-explanatory), style, docs, test.
As a scope, you can use whatever you like to specify what was this commit about.
It's better to provide the Jira task in the commit name so later we can keep track where some bug was fixed.

Try to use imperative mood in the commit name.

Each repository should follow a semantic versioning (the version should match this pattern: major.minor.patch).
When you've added a few feature, then bump the minor version, when you've fixed something, bump the patch version. If there are breaking changes, bump the major version.

You can use commitlint for validating the commit message and put it as a git hook.
Also you can (and it's better to) use conventional-changelog to generate the changelog based on the commits and use it as a post-hook for version upgrade.

For more info and examples, check out oms-frontend, oms-statutory and oms-events repos, which have it integrated.