seb/saltylab-firmware
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

Branch strategy: SaltyLab / SaltyRover / SaltyTank variants + dev branches #28

New Issue
Closed
opened 2026-02-28 18:47:12 -05:00 by seb · 0 comments
seb commented 2026-02-28 18:47:12 -05:00
Owner
Copy Link

Request

We need a proper branching strategy to support multiple chassis/sensor/wheel variants without agents stepping on each other.

Variants

Branch Description
saltylab Original 2-wheel self-balancing bot (current main)
saltyrover 4-wheel rover variant (different chassis, sensors, wheel config)
saltytank Tracked/tank variant

Branch Structure (per variant)

saltylab          ← stable, reviewed, tested
saltylab-dev      ← agents work here, PRs merge to saltylab

saltyrover        ← stable
saltyrover-dev    ← agents work here

saltytank         ← stable
saltytank-dev     ← agents work here

Rules

  • Agents create feature branches off <variant>-dev, PR back to <variant>-dev
  • Reviewed/tested code gets promoted from -dev to the stable variant branch
  • Shared firmware code (IMU drivers, USB CDC, balance core) lives in main and gets merged into variant branches
  • Each agent works in their own feature branch off the appropriate -dev — no direct commits to stable or dev

Action

@max — Please orchestrate:

  1. Create the branch structure
  2. Update agent CLAUDE.md / working instructions to use correct base branches
  3. Decide which shared code stays in main vs variant-specific
  4. Assign agents to variants based on current workload

This avoids the current problem of everyone working on main with different chassis assumptions.

## Request We need a proper branching strategy to support multiple chassis/sensor/wheel variants without agents stepping on each other. ### Variants | Branch | Description | |--------|-------------| | `saltylab` | Original 2-wheel self-balancing bot (current main) | | `saltyrover` | 4-wheel rover variant (different chassis, sensors, wheel config) | | `saltytank` | Tracked/tank variant | ### Branch Structure (per variant) ``` saltylab ← stable, reviewed, tested saltylab-dev ← agents work here, PRs merge to saltylab saltyrover ← stable saltyrover-dev ← agents work here saltytank ← stable saltytank-dev ← agents work here ``` ### Rules - Agents create feature branches off `<variant>-dev`, PR back to `<variant>-dev` - Reviewed/tested code gets promoted from `-dev` to the stable variant branch - Shared firmware code (IMU drivers, USB CDC, balance core) lives in `main` and gets merged into variant branches - Each agent works in their own feature branch off the appropriate `-dev` — no direct commits to stable or dev ### Action @max — Please orchestrate: 1. Create the branch structure 2. Update agent CLAUDE.md / working instructions to use correct base branches 3. Decide which shared code stays in `main` vs variant-specific 4. Assign agents to variants based on current workload This avoids the current problem of everyone working on `main` with different chassis assumptions.
seb closed this issue 2026-02-28 18:56:21 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
shaytac sl-controls sl-firmware sl-jetson sl-mechanical sl-perception sl-uwb sl-webui seb
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: seb/saltylab-firmware#28
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?