45 lines
3.0 KiB
Markdown
45 lines
3.0 KiB
Markdown
# Development Guidelines
|
|
|
|
This document outlines the best practices for Go development and Git workflow to be followed by the Gemini agent for this project.
|
|
|
|
## Go Development Guidelines
|
|
|
|
### Code Quality and Style
|
|
- **Formatting:** All Go code MUST be formatted with `gofmt` before committing.
|
|
- **Linting:** Use `golangci-lint` to enforce code quality and style.
|
|
- **Simplicity:** Write simple, clear, and concise code. Avoid unnecessary complexity.
|
|
- **Error Handling:** Handle all errors explicitly. Never ignore an error. Check for errors and return them from functions.
|
|
- **Naming:** Use meaningful and descriptive names for variables, functions, and packages. Follow Go's naming conventions (e.g., `camelCase` for private, `PascalCase` for public).
|
|
- **Comments:** Write comments to explain the *why* behind complex or non-obvious code, not the *what*. Document all public functions and packages.
|
|
- **Testing:**
|
|
- Write unit tests for all new code. Aim for high test coverage.
|
|
- Use table-driven tests for testing multiple scenarios.
|
|
- Mocks and interfaces should be used to isolate dependencies for testing.
|
|
- **Dependencies:** Use Go modules (`go mod`) to manage project dependencies. Keep the `go.mod` and `go.sum` files up-to-date.
|
|
|
|
### Best Practices
|
|
- **Concurrency:** When using goroutines, ensure proper synchronization to avoid race conditions. Use channels for communication between goroutines.
|
|
- **Interfaces:** Use interfaces to define behavior and decouple components.
|
|
- **Packages:** Structure your code into logical packages. Avoid circular dependencies.
|
|
- **Security:** Be mindful of security best practices. Sanitize inputs, avoid SQL injection, and handle credentials securely.
|
|
|
|
## Git Workflow Best Practices
|
|
|
|
### Branching
|
|
- **Main Branch:** The `main` branch is for production-ready code only. Direct commits to `main` are NOT allowed.
|
|
- **Feature Branches:** Create a new branch for every new feature or bug fix.
|
|
- Branch names should be descriptive and follow the pattern `feature/<short-description>` or `fix/<short-description>` (e.g., `feature/user-auth`, `fix/login-bug`).
|
|
- **Pull Requests (PRs):** All changes must be submitted through a Pull Request to the `main` branch.
|
|
|
|
### Committing
|
|
- **Atomic Commits:** Each commit should represent a single, logical change. Do not bundle unrelated changes into one commit.
|
|
- **Commit Messages:** Follow the [Conventional Commits](https://www.conventionalcommits.org/) specification. This helps in automating changelogs and versioning.
|
|
- **Format:** `<type>[optional scope]: <description>`
|
|
- **Example:** `feat: add user login endpoint`
|
|
- **Common types:** `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`.
|
|
|
|
### Pull Request (PR) Process
|
|
1. **Create a PR:** When your feature or fix is complete, create a PR against the `main` branch.
|
|
2. **CI Checks:** Ensure all automated checks (build, tests, linting) pass.
|
|
3. **Code Review:** The PR will be reviewed. Address any feedback by pushing new commits to your branch.
|
|
4. **Merge:** Once the PR is approved and all checks pass, it will be merged into `main`. |