|
| 1 | +# Contributing to git-mob |
| 2 | + |
| 3 | +Thank you for considering contributing to git-mob! This document provides guidelines and information for contributors. |
| 4 | + |
| 5 | +Not all pull requests or suggestions will be accepted, and maintainers reserve the right to decline changes for any reason, including technical direction, maintainability, or other considerations. |
| 6 | +By participating in this project, you agree to abide by our Code of Conduct. |
| 7 | + |
| 8 | +## Code of Conduct |
| 9 | + |
| 10 | +This project adheres to the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. |
| 11 | + |
| 12 | +## How to Contribute |
| 13 | + |
| 14 | +### Reporting Bugs |
| 15 | + |
| 16 | +- Use the GitHub issue tracker to report bugs |
| 17 | +- The bug report template will guide you through providing the necessary details |
| 18 | + |
| 19 | +### Suggesting Features |
| 20 | + |
| 21 | +- Use the GitHub issue tracker to suggest new features |
| 22 | +- The feature request template will help you structure your proposal |
| 23 | + |
| 24 | +### Pull Requests |
| 25 | + |
| 26 | +1. Fork the repository |
| 27 | +2. Create a feature branch from `main` |
| 28 | +3. Make your changes following the guidelines below |
| 29 | +4. Test your changes thoroughly |
| 30 | +5. Ensure all CI checks pass |
| 31 | +6. Maintain or improve code coverage - new code should be well-tested |
| 32 | +7. Submit a pull request with a clear description |
| 33 | + |
| 34 | +## Development Setup |
| 35 | + |
| 36 | +### Prerequisites |
| 37 | + |
| 38 | +- [Rust](https://www.rust-lang.org/tools/install) (latest stable) |
| 39 | +- [Git](https://git-scm.com/downloads) v2.32 or later |
| 40 | +- On Windows: [Microsoft C++ Build Tools](https://learn.microsoft.com/en-us/windows/dev-environment/rust/setup#install-visual-studio-recommended-or-the-microsoft-c-build-tools) |
| 41 | + |
| 42 | +### Getting Started |
| 43 | + |
| 44 | +1. Clone the repository: |
| 45 | + |
| 46 | + ```bash |
| 47 | + git clone https://github.com/Mubashwer/git-mob.git |
| 48 | + cd git-mob |
| 49 | + ``` |
| 50 | + |
| 51 | +2. Build the project: |
| 52 | + |
| 53 | + ```bash |
| 54 | + cargo build |
| 55 | + ``` |
| 56 | + |
| 57 | +3. Run tests: |
| 58 | + |
| 59 | + ```bash |
| 60 | + cargo test |
| 61 | + ``` |
| 62 | + |
| 63 | +4. Run the tool locally: |
| 64 | + ```bash |
| 65 | + cargo run -- --help |
| 66 | + ``` |
| 67 | + |
| 68 | +### IDE Setup |
| 69 | + |
| 70 | +#### VS Code (Recommended) |
| 71 | + |
| 72 | +1. Install the official [Rust extension](https://marketplace.visualstudio.com/items?itemName=rust-lang.rust-analyzer) |
| 73 | +2. Configure format on save for Rust files by adding to your settings.json: |
| 74 | + |
| 75 | + ```json |
| 76 | + { |
| 77 | + "[rust]": { |
| 78 | + "editor.formatOnSave": true |
| 79 | + } |
| 80 | + } |
| 81 | + ``` |
| 82 | + |
| 83 | + The rust-analyzer extension will automatically use your project's `rustfmt.toml` configuration if present. |
| 84 | + |
| 85 | +#### Other IDEs |
| 86 | + |
| 87 | +- **RustRover**: Use JetBrains' dedicated [RustRover IDE](https://www.jetbrains.com/rust/) |
| 88 | + |
| 89 | +## Development Guidelines |
| 90 | + |
| 91 | +### Code Style |
| 92 | + |
| 93 | +- **Formatting**: Use `cargo fmt --all` to format your code |
| 94 | +- **Linting**: Run `cargo clippy --all-targets --all-features -- -D warnings` to check for lints |
| 95 | +- **Documentation**: Add doc comments for public APIs using `///` |
| 96 | +- **Testing**: Write tests for new functionality and bug fixes |
| 97 | +- **Backwards Compatibility**: Strive to maintain backwards compatibility whenever possible. If breaking changes are necessary, clearly document them and provide migration guidance |
| 98 | + |
| 99 | +### Commit Messages |
| 100 | + |
| 101 | +This project uses [Conventional Commits](https://www.conventionalcommits.org/). Format your commit messages as: |
| 102 | + |
| 103 | +``` |
| 104 | +<type>[optional scope]: <description> |
| 105 | +``` |
| 106 | + |
| 107 | +**Common types:** `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore` |
| 108 | + |
| 109 | +**Examples:** |
| 110 | + |
| 111 | +``` |
| 112 | +feat: add support for adding non-team member to mob session |
| 113 | +
|
| 114 | +fix: resolve clippy warnings in test files |
| 115 | +
|
| 116 | +docs: update contributing guidelines |
| 117 | +
|
| 118 | +chore: update CI to use more comprehensive clippy checks |
| 119 | +``` |
| 120 | + |
| 121 | +### Testing |
| 122 | + |
| 123 | +- Write unit tests for new functionality |
| 124 | +- Integration tests should be placed in the `tests/` directory |
| 125 | +- Use descriptive test names that explain what is being tested |
| 126 | +- Test both success and failure scenarios |
| 127 | +- Run the full test suite before submitting: `cargo test` |
| 128 | + |
| 129 | +### Documentation |
| 130 | + |
| 131 | +- Update the README.md if you add new features or change existing behavior |
| 132 | +- Add inline documentation for complex logic |
| 133 | +- Update help text and command documentation as needed |
| 134 | + |
| 135 | +## Project Structure |
| 136 | + |
| 137 | +``` |
| 138 | +├── src/ |
| 139 | +│ ├── lib.rs # Library root |
| 140 | +│ ├── main.rs # CLI entry point |
| 141 | +│ ├── cli.rs # Command line interface |
| 142 | +│ ├── helpers.rs # Utility functions |
| 143 | +│ ├── commands/ # Command implementations |
| 144 | +│ └── repositories/ # Data access layer |
| 145 | +├── tests/ # Integration tests |
| 146 | +├── docs/ # Documentation |
| 147 | +└── target/ # Build artifacts |
| 148 | +``` |
| 149 | + |
| 150 | +## Code Quality |
| 151 | + |
| 152 | +### Before Submitting |
| 153 | + |
| 154 | +Run these commands to ensure your code meets the project standards: |
| 155 | + |
| 156 | +```bash |
| 157 | +# Format code |
| 158 | +cargo fmt --all |
| 159 | + |
| 160 | +# Check for lints |
| 161 | +cargo clippy --all-targets --all-features -- -D warnings |
| 162 | + |
| 163 | +# Run tests |
| 164 | +cargo test |
| 165 | + |
| 166 | +# Check documentation |
| 167 | +cargo doc --no-deps --open |
| 168 | +``` |
| 169 | + |
| 170 | +### Continuous Integration |
| 171 | + |
| 172 | +The CI pipeline runs: |
| 173 | + |
| 174 | +- Code formatting checks |
| 175 | +- Clippy linting with all warnings as errors |
| 176 | +- Tests on multiple platforms (Linux, macOS, Windows) |
| 177 | +- Security audit |
| 178 | +- Code coverage reporting |
| 179 | + |
| 180 | +## Release Process |
| 181 | + |
| 182 | +Releases are automated using [release-please](https://github.com/googleapis/release-please): |
| 183 | + |
| 184 | +1. **Automatic Release PRs**: release-please creates and maintains a release PR based on conventional commits |
| 185 | +2. **Version Bumping**: Versions are automatically determined from commit types (feat = minor, fix = patch, breaking = major) |
| 186 | +3. **Changelog Generation**: `CHANGELOG.md` is automatically updated based on conventional commits |
| 187 | +4. **Release Creation**: When the release PR is merged: |
| 188 | + - Version is bumped in `Cargo.toml` |
| 189 | + - Git tag is created |
| 190 | + - GitHub release is published |
| 191 | + - Crate is published to crates.io |
| 192 | + |
| 193 | +**For Contributors**: Simply follow the conventional commit format - the release process handles the rest automatically! |
| 194 | + |
| 195 | +## Getting Help |
| 196 | + |
| 197 | +- Check existing issues and discussions |
| 198 | +- Ask questions in GitHub discussions |
| 199 | +- Join the project's community channels if available |
| 200 | + |
| 201 | +## License |
| 202 | + |
| 203 | +By contributing, you agree that your contributions will be licensed under the [MIT License](LICENSE). |
0 commit comments