Files

T

jeanGaston 94b02198dd ci: build images from a dev branch and release tags, not every commit

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.

2026-07-30 12:03:20 +02:00

2.7 KiB

Raw Blame History

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:

<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.

2.7 KiB Raw Blame History