mirror of
https://github.com/SkalaraAI/skalara.git
synced 2025-04-09 15:10:16 -04:00
79 lines
2.8 KiB
Markdown
79 lines
2.8 KiB
Markdown
# CONTRIBUTION GUIDE
|
|
|
|
## Introduction
|
|
|
|
Welcome to Skalara's contribution guide! This document will guide you through our workflow, ensuring consistent and quality contributions. Please read it carefully and refer back to it when in doubt.
|
|
|
|
## Setup
|
|
|
|
1. Clone the repository to your local machine.
|
|
2. Ensure you have all necessary tools and dependencies installed as outlined in the `README.md`.
|
|
|
|
## Branching Strategy
|
|
|
|
We use a simple branching strategy:
|
|
|
|
- `main`: This branch contains production-ready code.
|
|
- `dev`: This is where new features and bug fixes are merged before they are tested and ready for production.
|
|
- `feature/your-feature-name`: For new features.
|
|
- `bugfix/your-bugfix-name`: For bug fixes.
|
|
- `hotfix/your-hotfix-name`: For hotfixes.
|
|
|
|
### Steps:
|
|
|
|
1. Always pull the latest changes from `dev` before creating a new branch.
|
|
2. Branch off from `dev` for features or bug fixes.
|
|
3. Name your branch appropriately based on the task at hand.
|
|
|
|
## Development Workflow
|
|
|
|
1. **Identify the Task**:
|
|
|
|
- Start with a clear understanding of the task at hand. This could be a new feature or a bug fix.
|
|
- An issue should be created on GitHub to represent this task.
|
|
|
|
2. **Branching**:
|
|
|
|
- Pull the latest version of `dev`.
|
|
- Create a new branch specific to your task.
|
|
|
|
3. **Coding**:
|
|
|
|
- Develop your feature or fix the bug in your branch.
|
|
- Commit often with clear, concise commit messages.
|
|
|
|
4. **Testing**:
|
|
|
|
- Test your changes thoroughly in your local environment.
|
|
- Ensure it adheres to the acceptance criteria mentioned in the task.
|
|
|
|
5. **Pushing Changes**:
|
|
|
|
- Push your branch and changes to the GitHub repository.
|
|
|
|
6. **Pull Request (PR)**:
|
|
|
|
- Create a PR from your branch to `dev`.
|
|
- Provide a detailed PR message, explaining your changes and any instructions for testing.
|
|
- Request reviews from appropriate team members.
|
|
|
|
7. **Code Review**:
|
|
|
|
- Address any feedback or changes requested by reviewers.
|
|
- Make required changes and push updates to the same branch.
|
|
|
|
8. **Merging**:
|
|
- Once the PR is approved, it will be merged into `dev`.
|
|
- Delete the feature/bugfix branch after merging, to keep the repository clean.
|
|
|
|
## Best Practices
|
|
|
|
1. **Commit Messages**: Write meaningful commit messages that provide a clear understanding of the changes. Reference this [semantic commit guide](https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716) for more information.
|
|
2. **Atomic Commits**: Each commit should represent a single logical change. Avoid bundling unrelated changes.
|
|
3. **Pull Often**: Regularly pull from `dev` to avoid major merge conflicts.
|
|
4. **Communication**: If stuck or in doubt, communicate. Use GitHub comments, or other communication tools adopted by the team.
|
|
|
|
## Conclusion
|
|
|
|
Your adherence to this guide ensures that our codebase remains clean, understandable, and easy to navigate. Happy coding!
|