# 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!