Team Workflow (Configuration Management)

Branches we use

• main: protected and only for stable, “final” code
• dev: where we combine everyone’s work and test before main
• feature branches: where each person works on a task

Core rules

• No direct pushes to main
• All changes go through a Pull Request (PR)
• PRs into main need at least 1 approval
• Keep PRs focused (ideally one feature or fix)

Normal workflow

1. Create an Issue for the task
2. Create a feature branch from dev
3. Commit your changes to that branch
4. Open a PR into dev
5. When dev looks good, open a PR from dev into main

Naming guidelines

• Branch names should be short and clear, like feature-login or bugfix-crash
• Commit messages should explain what changed, like “Add search bar” or “Fix API error”
• PR titles should clearly say what the change is

Reviews and merges

• The reviewer checks that it runs, doesn’t break anything, and matches the Issue
• If there’s a merge conflict, the PR creator fixes it
• Only merge to main when dev is stable and reviewed

Source of truth

• GitHub is our source of truth
• Using PRs keeps changes tracked and easy to roll back if needed