projects · hutfx · development · How we work on hutfx.com — development workflow · ✎ edit

How we work on hutfx.com — development workflow

Status: Locked — adopted 2026-11-01. This is how everyone works on this project from now on. Owner of the process: sato (hutfx / petya5q). Maintained by NEO.

1. Repository

Active repo: github.com/hutfx/lab-engine (this repo).
github.com/hutfx/hut_thereal is archive only — never work in it, never clean it.
Production site: https://hutfx.com served from /var/www/hutfx on hut (192.168.0.3), always on main.

2. Branch model

Branch	Meaning	Who touches it
`main`	Production. Always deployable.	Only the owner syncs it.
`active_work`	Integration layer. All finished work lands here first.	Only the owner merges PRs into it.
`<descriptive-name>`	Your feature/fix branch.	You, freely.

Rules: 1. Create your branch from the current active_work — name it descriptively (feat/user-portal, fix/login-redirect, docs/...). 2. Push your branch, open a Pull Request targeting active_work. 3. Only the owner merges into active_work. Never commit directly to active_work or main. 4. Production updates are a manual sync active_work → main by the owner. 5. git pull your env before starting work (see §4 update.sh).

3. Development environments (all on `hut`, 192.168.0.3)

Every developer has a private, full copy of the site — own clone, own database, own URL.

	URL	Code	Database	Samba	SSH
sato	http://sato.hutfx.com	`/home/sato/dev/hutfx`	`hutfx_sato`	`\\192.168.0.3\sato`	`ssh -p 2022 sato@192.168.0.3`
petya	http://petya.hutfx.com	`/home/petya/dev/hutfx`	`hutfx_petya`	`\\192.168.0.3\petya`	`ssh -p 2022 petya@192.168.0.3`
testhut (shared test)	http://testhut.hutfx.com	`/home/testhut/dev/hutfx`	`hutfx_testhut`	`\\192.168.0.3\testhut`	`ssh -p 2022 testhut@192.168.0.3`

Each home contains ACCESS.md — read it first: exact credentials, DB passwords, Thunderbird mail/calendar setup.
Linux login passwords: set by the owner. Samba password for all dev users: sato2.
The test environment tracks whatever branch the requester specifies at creation/request time; it is not automatic.
New environments are spawned by NEO on request: dev-spawn <name> <branch> (user, clone, DB, build, php-fpm, vhost, DNS, Samba, ACCESS.md — one command). update.sh <name> pulls a branch into an env on request.

4. Daily loop

cd ~/dev/hutfx
git fetch origin && git checkout -b <your-branch> origin/active_work   # start
# ... work, commit, push your branch ...
git push origin <your-branch>                                          # then open PR -> active_work

Never rebase/force-push a branch after a PR review has started.

5. Mail & team communication

Mailboxes: sato@hutfx.com, petya@hutfx.com, testhut@hutfx.com (IMAP mail.hutfx.com:993, SMTP mail.hutfx.com:465 SSL — see ACCESS.md for Thunderbird + calendar/address-book setup).
Team list: dev_hutfx@hutfx.com — send plans, reviews and announcements here; it reaches all developers.
Calendar/tasks/address book sync via SOGo CalDAV/CardDAV (URLs in each ACCESS.md). No chat server yet.

6. Credentials policy

Existing mailbox passwords are never reset without the owner's explicit OK.
Secrets live in each env's .env and ACCESS.md — do not paste them into the repo.

7. Definition of done (for any change)

Works in your own env on a feature branch.
PR opened against active_work with a clear description.
Owner reviews + merges; owner decides when active_work ships to main.

source: DOCS/hutfx/development/development-workflow.md · edit this page · rebuilt by build-wiki

Projects