- [ ] **Define your main branches.**
→ *Decide which long-lived branches you’ll maintain (e.g. `main`, `dev`, `release/*`). Write a short explanation in your README under “Branching Model.”*
- [ ] **Question:** What naming convention will you use for short-lived branches?
→ *Agree on a clear pattern (e.g. `feature/…`, `bugfix/…`, `docs/…`) and document it in the README.*
- [ ] **Question:** Will you include issue IDs in branch names?
→ *Adopt a pattern GitLab can auto-link to issues (e.g. `123-fix-login`). Create one example and verify the issue linkage appears automatically.*
- [ ] **Create one example branch of each type.**
→ *Demonstrate the structure in practice (e.g. `feature/login-page`, `bugfix/null-pointer`). Merge or close them once verified.*
- [ ] **Question:** Who is allowed to merge into main branches?
→ *Record your rule in the README or a pinned issue (e.g. “Only reviewers or maintainers can merge into `main`”).*
- [ ] **Set up branch protection rules if available.**
→ *Enable settings that prevent direct pushes to `main` or require approval before merge. Document what rules are active.*
- [ ] **Question:** How will you keep branches in sync?
→ *Define your update policy (e.g. “Rebase from `dev` before merge” or “Use merge commits only”). Write this rule where others can find it.*
- [ ] **Tag or label each branch’s purpose.**
→ *Optionally add descriptive tags or comments in merge requests to help track work origins (e.g. “Implements feature X”).*
- [ ] **Clean up old branches regularly.**
→ *Decide how and when you’ll remove stale branches (e.g. after merge + review) and document the rule briefly in the README.*
- [ ] **Question:** How will you visualize your branching model?
→ *Create a simple diagram or ASCII sketch and store it in `/docs/` or in the README to help onboard new team members.*