Our project follows a structured branching model to ensure clarity and maintainability. The branch structure includes:

• master: The main branch containing stable, production-ready code.
• Sprint branches: Named as sprint-1, sprint-2, and so on. Each sprint has its dedicated branch.
• Story branches: Named following the pattern a1-create-task, representing individual features or tasks.
• Hotfix branches: Created when necessary to address urgent issues.

Commit Naming Structure

Commits must follow Git best practices. Each commit message should:

• Use present tense verbs (e.g., "Create", "Fix", "Update").
• Clearly describe the work performed (e.g., "Create tests for navigation between screens").

Merge Workflow

For merges, we’ve decided on the following process:

1. The person opening the merge request assigns another team member to review it.
2. The assigned reviewer is responsible for either approving or closing the merge request.

This ensures accountability and avoids merging unchecked code.

Source Branch Deletion

To maintain traceability during the sprint, source branches will not be deleted after merging. Branches will remain until the sprint is completed.

Visualizing the Branch Structure

GitLab offers a dedicated feature to visualize the repository’s branch structure:

• Navigate to Code > Repository Graph to view a clear graph of branches and merges.

This provides a quick overview of the repo’s state and helps track progress.