Skip to content

Git convention

Make sure you follow Semantic Versioning

Version numbers are handled automatically by using semantic-release.

Commit Messages

For consistency, please write commit messages in the imperative mood.

A clear and concise commit message helps others understand the purpose of the commit and makes it easier to search through the history for specific changes.

Why the Imperative Mood?

The imperative mood matches the implied "command" to the codebase. Think of the message as completing the phrase: "This commit will...". For example:

  • "Fix bug" (instead of "Fixed bug")
  • "Add feature" (instead of "Added feature")
  • "Refactor code" (instead of "Refactored code")

This convention helps maintain consistency and clarity across the Eufemia codebase.

Decorate your commit messages

Make sure to decorate your commit messages with either Conventional Commits or simple-commit-message:

  • fix: fix message as the subject
  • feat: feature message as the subject
  • For a major change: feat: message + BREAKING CHANGE: in the footer of the commit. See example below.

If you are working on a single component update, you can use a decoration and a scope in parenthesis:

  • fix(ExampleComponent): an example fix message
  • feat(ExampleComponent): this is a new feature

You can also use the following decorators – but keep in mind, they won't be included in the releases change log:

  • chore:
  • docs:
  • style:
  • build:
  • ci:
  • refactor:
  • perf:
  • test:

Example of a breaking change commit message:

feat: commit subject with optional decorator
Body with text
Several lines
BREAKING CHANGE:
Subject (will be a list item):
Markdown text over several lines.
Additional text such as:
1. List item
2. List item

You can find more info in the docs of semantic-release and Conventional Commits.

Ignore CI run

You can either include [skip ci] in your commit message or let your branch name end with --skip-ci.

Rebasing

Squash commits

If you have to make a small fix after you committed:

  • Make and commit the new change
  • Squash and rebase with the previous commit
  • Force push to your branch

Rebase onto main

If you are working on a branch for a long period, it might be necessary to do a rebase on main once in a while:

git fetch origin && git rebase origin/main

Pull Requests

When you have committed changes to your branch, go to Github Pull Requests and open a New pull request.

Screenshot of the location of new pull request button on Github

You will most likely get the yellow notification bar mentioning that a branch had a recent push. Click on the Compare and pull request button. This will take you to the page for opening a pull request. Fill out the template under the Write tab.

Screenshot of opening a new pull request on Github

Request a reviewer, create the pull request and watch the results of the pipeline checks.