Development Workflow Documentation - bounswe/bounswe2026group4 GitHub Wiki

GitHub Branching Strategy

🎯 Purpose

This branching strategy aims to:

  • Maintain code quality
  • Reduce merge conflicts
  • Keep development organized
  • Ensure the stability of the main branch
  • Enforce mandatory peer review

🌳 Branch Structure

main:

  • Primary production-ready branch
  • Must always be runnable and stable
  • Direct push is not allowed
  • All changes must go through a Pull Request
  • Requires at least 1 reviewer approval

feat/short-description:

Feature branches

Example:

  • feat/user-authentication
  • feat/map-filtering
  • feat/mobile-onboarding Rules:
  • Created from main
  • Must be merged via Pull Request
  • Requires review approval

fix/short-description:

Bug fix branches

Example:

  • fix/login-validation-error
  • fix/timeline-crash Rules:
  • Created from main
  • Must go through Pull Request
  • Requires at least 1 approval

Commit Message Convention

🎯 Purpose

  • Keep commit history clean and professional
  • Improve traceability
  • Make changes clear and understandable

📌 Format

type : short description

✅ Allowed Types

  • feat → New feature
  • fix → Bug fix
  • refactor → Code improvement (no behavior change)
  • docs → Documentation changes
  • test → Test updates

Examples

feat: add mobile onboarding screen fix: resolve crash on map zoom refactor: simplify authentication middleware docs: update branching strategy documentation

❌ Avoid

  • update
  • changes
  • wip
  • unclear or random messages
  • Every commit must clearly describe what was changed and why.

Pull Request Workflow

PR is Mandatory

All changes to main must go through a Pull Request

Direct push to main is not permitted

🪜 PR Steps

  • Create a branch from main
  • Implement changes
  • Commit using the defined convention
  • Push branch
  • Open a Pull Request targeting main
  • Request review
  • Address feedback
  • Merge after approval

👀 Review Rules

  • At least 1 reviewer approval is required
  • Self-approval is not preferred
  • All review comments must be resolved before merging

Reviewers should check:

  • Code correctness
  • Edge cases
  • Readability
  • Naming consistency
  • Impact on existing functionality
  • Compliance with project conventions
  • Consistency with repository structure

✅ Merge Requirements

A Pull Request can be merged only if:

  • All relevant unit tests are added or updated
  • Existing functionality is covered by appropriate tests when necessary
  • All tests pass successfully
  • CI/CD checks pass successfully
  • The branch does not contain major merge conflicts
  • The code is readable and maintainable
  • The code follows the agreed repository structure
  • The implementation follows the defined branching, commit, and PR conventions
  • The PR is focused and does not include unrelated changes
  • Required review approval has been received

🔁 Workflow Summary

Issue → Branch → Commit → PR → Review → Merge

🧠 Best Practices

Keep PRs small and focused

Do not mix unrelated changes

Sync with latest main before merging

Communicate before major architectural changes

Never merge unreviewed code