🐱GitHub
Last updated
Last updated
In our development process, we utilize branches, pull requests, and merges to organize and integrate our code changes effectively. Here's our workflow:
When picking up a new card from our Kanban board here, always create a new branch based on the develop branch. The branch name should start with issue_[issue_number_linked_to_the_card].
As you work on the task, make commits to your branch as needed. Each commit message should follow our Commit Message Conventions , with a prefix indicating the type of change and a concise description.
After completing the task and making N commits, create a pull request to merge your branch into the develop branch. When creating the pull request, use the "Squash and merge" option to consolidate your commits into a single meaningful commit.
The pull request to merge changes into the mainbranch can only be made from the develop branch to main. When creating this pull request, choose the "Create a merge commit" option to maintain a clear history of changes.
Following this workflow ensures that our codebase remains organized, changes are reviewed, and our development process is efficient and collaborative.
When making commits to the repository, we follow a set of conventions to maintain consistency and clarity in our commit messages. Each commit message begins with a prefix indicating the type of change being made, followed by a concise description of the change.
In this example, the commit introduces a new feature related to issue #11, with a descriptive comment for this commit. When the commit is related to an issue, always link the issue number before the comment using #.
Adhering to these conventions helps us maintain a clear and organized commit history, making it easier to understand the changes introduced at a glance.
| Prefix | Definition |
|---|---|
FIX🐛
Used for bug fixes.
PERF🚀
Indicates a performance improvement.
UX🎨
Denotes a user interface change.
SECURITY🔒
Signals a fix for a security problem.
FEAT✨
Represents an added feature.
DEV🛠️
Reserved for internals changes that don't fit into the above categories.