Devel→Client Update Workflow

How a senior engineer keeps a long-lived per-client deployment current with the moving core, using dated update/customization/<client>-<YYYY-MM-DD> branches.

Branch data is a point-in-time snapshot

Every branch count, name, and date below reflects the last-fetched local refs in /Users/levander/coding/facekom/vuer_oss as of 2026-05-30. These are refs/remotes/origin/* read with git for-each-ref/git log — no fetch was run. The live remote may have moved.

See also: INDEX · customization-architecture · customization-clients · customization-branch-catalog · testing · conventions-and-glossary

1. The branch model

vuer_oss is a code repo whose default branch is devel (verified: git symbolic-ref refs/remotes/origin/HEAD → refs/remotes/origin/devel). Core development lands on devel; clients live on long-lived branches that diverge from it.

Prefix	Meaning	Lifetime
devel	Core base; default branch, integration target for core work	permanent
feature/FKITDEV-####-<desc>	Ticket work, merged into devel	short-lived
customization/<client>	Per-client deployment branch (carries client overrides)	long-lived
update/customization/<client>-<YYYY-MM-DD>	Dated “merge devel into customization/<client>” snapshot	short-lived, recurring

Top-level branch-prefix tally in vuer_oss (verified: for-each-ref refs/remotes/origin | awk -F/ '{print $1}' | sort | uniq -c):

271 feature   154 customization   126 test   118 fix    86 save
 84 update     27 mod              22 cr      20 feat    15 release
 12 improvement 10 maintenance      8 bugfix    6 docs     5 upgrade
  4 refact / development / chore    3 backup    2 doc/dependabot/debug/change
  1 wip / hotfix / cleanup / bug / chore / test ...

Other prefixes the original brief calls out (cr/, fix/, bugfix/, build/, chore/, test/) are all present except build/ — in vuer_oss “build” work appears as ad-hoc branch names rather than a build/ prefix (e.g. PR #7148 build/watch-restart merged from a non-prefixed branch). bugfix/, fix/, cr/, chore/, test/ confirmed in the tally above.

Counts (verified wc -l on for-each-ref)

• 154 customization/* branches in vuer_oss
• 67 update/customization/* branches in vuer_oss
• 29 distinct clients appear in update/customization/* (see §2)

2. The update branch: naming, cadence, examples

Naming is update/customization/<client>-<YYYY-MM-DD> (a few legacy variants use a / before the date, e.g. update/customization/polgaribank/2025-10-20, update/customization/microsec/2025-09-23, and an even older update/instacash-devel-update-2025-04-25 / update/FKITDEV-####-<client>-devel-update-<date> form).

The branches are per-client and recurring — each client absorbs devel on its own schedule, several times a year. Real dated series (verified: for-each-ref --sort=committerdate refs/remotes/origin/update/customization):

bb (Budapest Bank) — 5 update branches

• update/customization/bb-2024-07-22
• update/customization/bb-2024-07-29
• update/customization/bb-2025-07-28
• update/customization/bb-2025-12-08
• update/customization/bb-2026-02-24

instacash — multiple, incl. the legacy form

• update/customization/instacash-2024-11
• update/customization/instacash-2025-11-12
• update/customization/instacash-2025-12-08
• update/customization/instacash-2026-05-27 ← currently checked out (§6)

Most-recently-committed update branches across all clients (verified: --sort=-committerdate): mbh-2026-05-12 (2026-05-15), magnet-2026-04-08, nusz-2026-03-24, magnet-2026-03-20, bb-2026-02-24, unicredit-srb-2026-02-12. A large cohort shares the 2025-12-08 stamp (bb, mbh, mvm, raiffeisen, unicredit, nusz, cib, szerencsejatek, instacash, granit, polgaribank, fundamenta, barion) — i.e. a fleet-wide devel sync round was run for many clients off the same devel snapshot.

Clients with the most update rounds (verified: strip date suffix, uniq -c): nusz (6, highest); raiffeisen, mkb-instant, bb (5 each); unicredit, szerencsejatek (4 each); then polgaribank, otp, mbh, magnet, instacash (3 each).

3. The mechanism: merge devel INTO the client

An update/customization/<client>-<date> branch is a dated snapshot of “merge origin/devel into customization/<client>”. It is not a rebase and not a cherry-pick — it is a real merge commit that pulls the whole current core into the client branch.

Verified on the live checkout update/customization/instacash-2026-05-27 (git log --oneline --merges -15 HEAD):

6baa792bd3 Merge pull request #7488 from TechTeamer/update/FKITDEV-7978-instacash-devel-update-2025-11-14
5eaaadab43 Merge branch 'devel' into customization/instacash
...
00556bbfe6 Merge pull request #7129 from TechTeamer/update/customization/instacash-2025-08-13
8dea48799c Merge branch 'devel' into update/customization/instacash-2025-08-13
...
7dc10054ad Merge branch 'devel' into update/instacash-devel-update-2025-04-25

The pattern repeats every round: a Merge branch 'devel' into customization/instacash (or into update/customization/instacash-<date>) commit, then a PR merge that lands the result. Merge parents confirm direction (verified git show --no-patch --format='%P'): 5eaaadab43 (Merge branch 'devel' into customization/instacash) has two parents — the client tip and a devel commit — i.e. devel is merged into the client side.

Cross-repo

The workflow spans repos. esign_oss carries the same update/customization/instacash-2026-05-27 branch (committed 2026-05-29) plus 9 update/customization/* and 15 customization/* branches of its own (verified in /Users/levander/coding/facekom/esign_oss). A client update round is coordinated across vuer_oss + esign_oss (+ CSS repos).

4. Why it exists (the core-override risk)

Each client lives on customization/<client> and diverges as it carries client-specific overrides; meanwhile devel keeps moving with new core features and fixes. Periodically every client must absorb devel — but customization branches also modify CORE files, so merging devel risks conflicts and behavioural breakage exactly where the client overrode core.

Measure the overlap read-only with --name-status (NEVER a full git diff — the instacash tree is hundreds of files and the full patch can run to ~140k lines). Verified for instacash (git diff --name-status origin/devel...origin/customization/instacash): 365 changed paths = 77 modified (M) + 287 added (A) + 1 rename (R). The single R is an R100 pure rename (customization/overrides/.gitkeep → docs/features/reports/feedbacks/developer.md); the instacash client CLI (bin/instacash-cli.js) is itself one of the 287 A (added) files, not a separate category. The M entries are the danger zone — core files the client has edited:

M  client/features/flow/ui/FlowPreview/FlowPreview.styl
M  client/features/videochat/room/RemoteUser/RemoteUser.js
M  client/ui/pages/customerProfile/customerProfile.template.twig
M  config.js
M  config/roles.json
A  bin/instacash-cli.js
A  customization/RELEASE.md

When devel has touched any of those 77 M files since the last round, the merge will conflict — and a clean auto-merge that silently combines a core change with a client override is the higher risk. Cross-ref customization-architecture for the core-override model.

5. How to create one (steps implied by the branch structure)

Read-only investigation only in this vault's workflow

The commands below are what an engineer runs in a working clone. This discovery pass itself used read-only git only (log/show/for-each-ref/diff --name-status/ls-tree); it never ran checkout/fetch/merge/full-diff.

1. Branch off the client: git switch customization/<client> then git switch -c update/customization/<client>-$(date +%F).
2. Survey the overlap first: git diff --name-status origin/devel...origin/customization/<client> — note every M (modified-core) path; those are the expected conflict sites.
3. Merge devel in: git merge origin/devel (produces the Merge branch 'devel' into ... commit seen in §3).
4. Resolve conflicts, concentrating on the client’s overridden core files from step 2 (config.js, roles, twig templates, flow/videochat JS). Keep the client override’s intent while taking the core’s new logic.
5. Commit / push the update branch for review.

6. How to test it (cross-ref testing)

Test ON the update branch, not on devel

The point of the dated branch is to validate the merged result before it reaches the client’s deployment branch.

• Run the client’s unit + e2e suites on the update/customization/<client>-<date> branch.
• Re-review the devel↔client core-file overlap (diff --name-status, §4) to catch every place devel touched a file the client overrode — these are where merged behaviour can silently drift.
• Verify client-specific behaviour still holds: flows, emails, and CV (computer-vision / document checks) — the instacash diff shows the client edits flow UI, NFC checks, sidebar, and config/roles.json, so those surfaces need a manual pass.

(See testing for the concrete suite commands. Note: a dedicated testing.md was not yet present in this vault folder at verification time — this wikilink is the canonical target for that page.)

7. How it lands

The update branch is PR’d back into customization/<client> (not into devel). Real merged PRs in vuer_oss history for instacash (verified git log --oneline | grep 'Merge pull request'):

PR	Source branch
#7488	update/FKITDEV-7978-instacash-devel-update-2025-11-14
#7129	update/customization/instacash-2025-08-13
#6388	update/customization/instacash-2025-01
#5912	update/customization/instacash-2024-10-15
#5466	update/customization/instacash-2024-07-23

The PR merge parents (verified for #7129 00556bbfe6) join the customization line with the update branch — i.e. the update branch flows into the client’s long-lived branch, closing the round.

8. The live example: instacash-2026-05-27

What is currently checked out across the working tree (verified git rev-parse --abbrev-ref HEAD per repo):

Repo / worktree	Branch
vuer_oss	update/customization/instacash-2026-05-27
esign_oss	update/customization/instacash-2026-05-27
esign_css	update/customization/instacash-2026-05-27
vuer_css-instacash-update (worktree at /Users/levander/coding/facekom/vuer_css-instacash-update)	update/customization/instacash-2026-05-27
portal_css	customization/instacash

This is the in-progress 2026-05-27 round bringing customization/instacash up to current devel. To inspect it read-only:

# the merge structure of this round
git -C vuer_oss log --oneline --merges -15 HEAD
 
# what the client overrides vs devel (danger zone = M lines)
git -C vuer_oss diff --name-status origin/devel...origin/customization/instacash
 
# where this round sits relative to the client's deployed tip
git -C vuer_oss rev-list --left-right --count origin/customization/instacash...HEAD

State at verification

git rev-list --left-right --count origin/customization/instacash...HEAD returned 0 0 — the local checkout of update/customization/instacash-2026-05-27 sits exactly at origin/customization/instacash (no divergence in either direction) in the last-fetched refs. Read either as: this round’s merge-back has already been reflected into the local customization/instacash ref, or the dated branch and the client tip are coincident at the snapshot. Re-fetch to see the live position.

Sources

All commands run read-only in /Users/levander/coding/facekom/vuer_oss (and esign_oss, sibling repos) on 2026-05-30; refs are last-fetched origin/*, no fetch performed.

• git -C vuer_oss rev-parse --abbrev-ref HEAD → update/customization/instacash-2026-05-27
• git -C vuer_oss symbolic-ref refs/remotes/origin/HEAD → refs/remotes/origin/devel (default = devel)
• git -C vuer_oss for-each-ref refs/remotes/origin/customization | wc -l → 154
• git -C vuer_oss for-each-ref refs/remotes/origin/update/customization | wc -l → 67
• git -C vuer_oss for-each-ref refs/remotes/origin | sed 's#^origin/##' | awk -F/ '{print $1}' | sort | uniq -c | sort -rn → prefix tally (§1)
• git -C vuer_oss log --oneline --merges -15 HEAD → PR #7488, Merge branch 'devel' into customization/instacash, PR #7129, Merge branch 'devel' into update/customization/instacash-2025-08-13 (§3)
• git -C vuer_oss show --no-patch --format='%P' 5eaaadab43 00556bbfe6 → two-parent merges proving devel→client direction
• git -C vuer_oss for-each-ref --sort=committerdate ... refs/remotes/origin/update/customization | grep '/bb-' | '/instacash' → dated series (§2)
• git -C vuer_oss for-each-ref refs/remotes/origin/update/customization | strip-date | uniq -c → 29 distinct clients, per-client counts (§2)
• git -C vuer_oss diff --name-status origin/devel...origin/customization/instacash | wc -l → 365 (awk '$1=="M"'→77, '$1=="A"'→287, one R100 rename) (§4)
• git -C vuer_oss log --oneline | grep 'Merge pull request .*update/customization|...devel-update' → PRs #7488, #7129, #6388, #5912, #5466 (§7)
• git -C vuer_oss rev-list --left-right --count origin/customization/instacash...HEAD → 0 0 (§8)
• git -C vuer_oss worktree list → vuer_css-instacash-update worktree on update/customization/instacash-2026-05-27
• git -C esign_oss for-each-ref refs/remotes/origin/update/customization → 9 update branches incl. instacash-2026-05-27 (2026-05-29); customization/* → 15 (§3 cross-repo)
• per-repo git rev-parse --abbrev-ref HEAD for vuer_oss/esign_oss/esign_css/portal_css → checkout table (§8)