Daniil
42 lines
1.3 KiB
Markdown
42 lines
1.3 KiB
Markdown
# Git Workflow
|
|
|
|
## Commit Message Format
|
|
|
|
```
|
|
<type>(<scope>): <description>
|
|
|
|
<optional body>
|
|
```
|
|
|
|
**Types:** feat, fix, refactor, docs, test, chore, perf, ci
|
|
**Scopes:** frontend, backend, remotion, infra, shared (or omit for cross-cutting)
|
|
|
|
Examples:
|
|
- `feat(frontend): add transcription progress bar to ActionPanel`
|
|
- `fix(backend): prevent duplicate job creation in tasks service`
|
|
- `refactor(remotion): extract caption animation into reusable spring`
|
|
- `chore(infra): update Docker Compose PostgreSQL to 16`
|
|
|
|
## Branch Naming
|
|
|
|
```
|
|
<type>/<short-description>
|
|
```
|
|
|
|
Examples: `feat/caption-styles`, `fix/upload-mime-validation`, `refactor/fsd-media-module`
|
|
|
|
## Pull Request Process
|
|
|
|
1. Run verification before creating PR (see `verification.md` rule)
|
|
2. Use `git diff main...HEAD` to see all changes from branch point
|
|
3. Summarize ALL commits (not just the latest) in PR description
|
|
4. Include test plan with specific scenarios
|
|
5. Push with `-u` flag for new branches
|
|
|
|
## Monorepo Considerations
|
|
|
|
- Commits should touch ONE subproject when possible
|
|
- Cross-service changes (e.g., new API endpoint + frontend consumer) go in separate commits within the same PR
|
|
- Migration commits go BEFORE the code that uses them
|
|
- Never commit `.env`, credentials, or lock files across subprojects
|