Thank you for considering contributing to this project! Please follow these guidelines to help us maintain a high-quality, welcoming, and consistent open-source ecosystem.
This project adheres to the Contributor Covenant Code of Conduct. By participating, you are expected to uphold this code. Violations should be reported to the maintainers.
- Go 1.20 or later
- PostgreSQL 12 or later
- Docker and Docker Compose (optional, for containerized PostgreSQL)
- Git
-
Clone the repository:
git clone https://github.com/aptlogica/go-postgres-rest.git cd go-postgres-rest -
Install dependencies:
go mod download go mod verify
-
Configure environment:
cp .env.example .env # Edit .env with your local PostgreSQL credentials -
Run tests:
go test -v -race -coverprofile=coverage.out ./... -
View coverage:
go tool cover -html=coverage.out -o coverage.html open coverage.html
feature/<name>- New features (e.g.,feature/add-query-builder)fix/<name>- Bug fixes (e.g.,fix/connection-pool-leak)docs/<name>- Documentation updates (e.g.,docs/update-api-reference)refactor/<name>- Code refactoring (e.g.,refactor/simplify-repo-factory)chore/<name>- Maintenance tasks (e.g.,chore/update-dependencies)release/<version>- Release preparation (e.g.,release/v1.0.0)
Branch names should be:
- Lowercase
- Hyphen-separated
- Descriptive but concise
- Limited to 50 characters
This project follows Conventional Commits:
<type>(<scope>): <subject>
<body>
<footer>
feat- New featurefix- Bug fixdocs- Documentation changesstyle- Code style changes (formatting, missing semicolons, etc.)refactor- Code refactoring without feature changesperf- Performance improvementstest- Adding or updating testsbuild- Build system or dependency changesci- CI/CD pipeline changeschore- Maintenance tasks
Include the affected component:
postgres- PostgreSQL database codeconfig- Configuration modulemodels- Data modelsservices- Business logic servicesutils- Utility functionsexamples- Example applications
feat(postgres): add bulk insert optimization
- Implement batch insert with configurable batch size
- Add BulkInsert method to repository interface
- Update performance benchmarks
Closes #42
fix(services): handle nil pointer on relationship sync
Previously failed when syncing empty relationships.
Now properly initializes relationship data.
Fixes #137
Before submitting a pull request:
- Ensure your branch is based on
mainand up to date - Code follows project style guidelines
- All tests pass:
go test -v -race ./... - Coverage maintained or improved:
go test -coverprofile=coverage.out ./... - Code linting passes:
go fmt ./... - Dead code removed: No unused imports or functions
- Documentation updated (README, docs/, code comments)
- Related issues referenced in PR description
- Commit messages follow Conventional Commits format
- Overall project: Minimum 90% coverage required for main release
- Critical functions: ParseValue, BuildComplexQuery, GetRelationshipData - minimum 85%
- New code: Must include tests with 80%+ coverage for new functions
# Run all tests
go test ./...
# Run with coverage
go test -v -race -coverprofile=coverage.out ./...
# Run specific test
go test -v ./pkg/database/postgres -run TestQueryBuilder
# Run benchmarks
go test -v -bench=. -benchmem ./...- Test files:
*_test.go - Internal tests:
*_internal_test.go(package-private testing) - Location: Same directory as code being tested
- Add entry to CHANGELOG.md with feature description
- Update relevant docs in
docs/directory - Include example usage in code comments or docs/
- Update README if user-facing
- Document changed signatures in migration guide
- Update API documentation in docs/
- Include deprecation notice if replacing existing API
- Public functions: Brief description + parameter/return documentation
- Complex logic: Inline comments explaining non-obvious code
- TODO/FIXME: Mark with
// TODO:or// FIXME:with issue reference
- Format: Follow
go fmtstandards (enforced by CI) - Naming: Use clear, descriptive names for variables and functions
- Errors: Always handle and propagate errors, never ignore
- Logging: Use structured logging for debugging
- Security: Never commit credentials, API keys, or sensitive data
- Create PR: Push your branch and open a PR with detailed description
- Automated checks: GitHub Actions must pass (tests, coverage, linting)
- Code review: At least one maintainer reviews changes
- Changes requested: Address feedback and push updates
- Approval: Maintainer approves and merges to main
- Update version in code and documentation
- Update CHANGELOG.md with release notes
- Create Git tag:
git tag -a vX.Y.Z -m "Release X.Y.Z" - Push tag:
git push origin vX.Y.Z - Create GitHub release:
gh release create vX.Y.Z --generate-notes
See VERSIONING.md for version numbering details.
- Questions: Open a GitHub Discussion or Issue
- Bugs: Report with reproducible steps in a GitHub Issue
- Security: See SECURITY.md for reporting vulnerabilities
- Chat: Join our community discussions
Contributors will be recognized in:
- GitHub contributor graph
- Project README
- Release notes (for significant contributions)
Thank you for contributing!