---
module: processes.develop
title: Develop Process
tab: Overview
order: 10
audience: bcos
---

How day-to-day work flows on `develop`. **BCOS admin only.**

## The rule
**Always work on `develop`, never `main` directly.** Every sub-project repo has branch protection
on `main`. Before any change, `cd` into the sub-project and confirm you're on `develop` (or a
feature branch off it).

**Repos that intentionally stay on `main`** (no `develop`): `hiveops-src` (monorepo root),
`hiveops-docs`, `hiveops-release`, `hiveops-devops`.

## Flow
1. **`git pull` first** — remotes move; skipping this causes rebase/merge conflicts on push.
2. `cd /source/hiveops-src/hiveops-<name>` → `git checkout develop`.
3. Make the change. For a new feature, branch off `develop`; for small/content changes, commit
   straight to `develop` (established pattern).
4. Push → open a **PR to `develop`** for feature branches (CI build + tests must pass), then merge.
5. **Deploy to bcos.dev first and smoke-test** the real path before calling it done — a green
   container is not a smoke test. Only then does it move toward `main` (see [[processes.main]]).

## Conventions
- Conventional commits: `feat(scope): …`, `fix`, `chore`, `docs`, `content`. End commit messages
  with the `Co-Authored-By: Claude …` line.
- **Commit before stopping** — never leave uncommitted work in any repo.
- **Issue first** — no code without a Gitea issue (see [[processes.gitea-issues]]).

## Do NOT
- Do NOT commit directly to `main` or bypass branch protection.
- Do NOT skip the bcos.dev smoke test before promoting.
