jeanGaston
94b02198dd
Every push to master was triggering a build+push, since that's where day-to-day commits land. Switch to two deliberate channels instead: pushing to dev produces a rolling :dev tag for testing, and pushing a v* tag produces :latest + the version tag for real releases. Plain commits/merges to master/main no longer build anything on their own.
74 lines
2.7 KiB
Markdown
74 lines
2.7 KiB
Markdown
# Git workflow
|
|
|
|
This project uses a lightweight trunk-based workflow. It's a solo/small-team
|
|
project, so the goal is just enough process to keep `main` deployable and the
|
|
history readable — not ceremony for its own sake.
|
|
|
|
## Branches
|
|
|
|
- `main` — always deployable. Nothing is committed to `main` directly except
|
|
by merging a branch through the steps below.
|
|
- `feat/<short-name>` — new functionality (e.g. `feat/gif-picker`).
|
|
- `fix/<short-name>` — bug fixes (e.g. `fix/expired-proposal-redirect`).
|
|
- `refactor/<short-name>` — internal changes with no user-facing behavior
|
|
change (e.g. `refactor/ui-ux-shadcn`).
|
|
- `chore/<short-name>` — tooling, deps, config.
|
|
|
|
Branch names are kebab-case and describe the change, not the ticket number
|
|
(there's no issue tracker yet).
|
|
|
|
## Commits
|
|
|
|
Follow [Conventional Commits](https://www.conventionalcommits.org/):
|
|
|
|
```
|
|
<type>(<optional scope>): <summary, imperative mood, no trailing period>
|
|
|
|
<optional body: why, not what>
|
|
```
|
|
|
|
Types: `feat`, `fix`, `refactor`, `style`, `docs`, `chore`, `test`.
|
|
|
|
- Keep commits small and focused — one logical change per commit.
|
|
- Write the summary in the imperative ("add", not "added"/"adds").
|
|
- Explain *why* in the body when the reason isn't obvious from the diff.
|
|
|
|
## Merging
|
|
|
|
- Rebase your branch on `main` before merging (`git fetch && git rebase
|
|
origin/main`) to keep history linear — don't merge `main` into a feature
|
|
branch.
|
|
- Squash-merge feature/fix/chore branches into `main` so each lands as one
|
|
commit. Larger `refactor/*` branches with independently meaningful commits
|
|
may use a regular merge instead of squashing, if keeping the granular
|
|
history is genuinely useful for a future bisect.
|
|
- Delete the branch after it's merged.
|
|
- Never force-push `main`. Force-pushing a feature branch you own (after a
|
|
rebase) is fine; never force-push a branch someone else might be using.
|
|
|
|
## Tags / releases
|
|
|
|
Tag production releases as `v<major>.<minor>.<patch>` (semver) once this
|
|
project has a deployment cadence worth marking. Not required for every merge.
|
|
|
|
## Docker images
|
|
|
|
CI (`.gitea/workflows/docker-publish.yml`) only builds an image on two
|
|
events, not on every commit:
|
|
|
|
- push to `dev` — builds a rolling `:dev` tag, for testing in-progress work
|
|
before it's ready to release.
|
|
- push a `v*` tag — builds `:latest` plus the version tag, for actual
|
|
releases.
|
|
|
|
Push to `dev` when you want a throwaway build to test; tag a release on
|
|
`main`/`master` when you want a real one.
|
|
|
|
## What not to commit
|
|
|
|
- Anything in `.gitignore` (`.env`, `/data`, `.next`, `node_modules`, prisma
|
|
migration SQL under `prisma/migrations/*/migration.sql`).
|
|
- Generated/build artifacts.
|
|
- Secrets of any kind, even in comments or examples — use `.env.example` for
|
|
documenting required variables.
|