Skip to content

Latest commit

 

History

History
67 lines (50 loc) · 3.3 KB

CONTRIBUTING.md

File metadata and controls

67 lines (50 loc) · 3.3 KB
Raw

Contributing to the Codebase 🚀

This document shares some best practices and tips for working on our code base.

Commit Message 📝

Write a good commit message that follows this format:

[optional emoji] [type]([optional scope]): [subject]
[BLANK LINE]
[optional body]

Where:

  • [optional emoji] is an optional emoji that represents the type of change. You can use https://gitmoji.dev/ to find suitable emojis for your commits. For example, you can use 🐛 for fix, ✨ for feat, ♻️ for refactor, etc.
  • [type] is one of these valid types: fix, feat, refactor, docs, test, chore. These types indicate what kind of change you made in your code. For example, fix means you fixed a bug, feat means you added a new feature, docs means you updated the documentation, etc.
  • ([optional scope]) is an optional scope that specifies what part of the code is affected by your change. For example, you can use (etl), (api), (db) to indicate which module or component you worked on.
  • [subject] is the message itself that briefly describes what changed and why. It should be concise and clear, preferably less than 50 characters. It should NOT start with a capital letter and should NOT end with a period. It should not explain how you changed the code, but what and why.
  • [BLANK LINE] is an empty line that separates the subject from the body.
  • [optional body] is an optional body that provides more details about your change. It should be written in paragraphs, each separated by a blank line. It should explain the problem you solved, how you solved it, and any other relevant information. It should wrap at 72 characters.

For example:

:sparkles: feat(etl): add new data source for customer segmentation

If you have multiple commits in one merge request, you should squash them into a single commit with a suitable commit message when merging with the main branch. The commit message should summarize what changes you made in the merge request and why. It should also reference the issue that you resolved and include the ticket number from Jira. For example:

:recycle: refactor(ansible): move dev machines group vars to the role vars #123

This indicates that you resolved ticket number 123, which was about refactoring the variables of development machines.

Branching Name Convention 🔀

Before creating a feature or resolving a bug, it is required to create an issue on GitHub. This issue will be assigned a number, which should be included in the branch name, separated by hyphens (-). Here is an example of a valid Git branch name:

2-feature-add-contribution-documentation

Feature Development 🛠️

To write a new feature, follow these steps:

  1. Create an issue in Github and explain what should be done or resolved.
  2. Create a pull request and a corresponding branch for the issue. Assign the task and review to appropriate people.
  3. Start committing in the specified branch. You can have separate changes in different commits in this branch. At the time of merging with the main branch, you should squash all of these commits into a single commit with an appropriate commit message for the whole merge request.
  4. After the commits, check for the running of CI which runs a lint and for some codes runs the appropriate tests. If something fails, fix them.