Git Workflow Guide for FoodBook

Overview

This document outlines the Git workflow to be followed by Team 23 of ISIS3510 202410. Adhering to this workflow will help maintain a structured and collaborative development process.

Branching Strategy

Feature Branches

• Create a new branch for each new feature or task.
• Naming convention: feature/{issue-number}-{short-description}
  • Example: feature/123-add-authentication

Release Branches

• Create a release branch when preparing for a new release.
• Naming convention: release/{version}
  • Example: release/1.0.0

Main Branch

• The main branch represents the stable production-ready code.
• Only merge feature and bugfix branches into main when they are thoroughly tested and approved.

Commit Guidelines

Commitizen

• We use Commitizen to standardize commit messages and generate a consistent changelog.
• You can install Commitizen using pip or npm, either way should be usable globally.
• You could also just follow these guidelines:

prefix	desc
feat	A new feature
fix	A bug fix
docs	Documentation only changes
style	Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor	A code change that neither fixes a bug or adds a feature
perf	A code change that improves
test	Add missing tests

• Example of a commit: feat: Added navigation components for main view

Pull Request Process

1. Create a new branch for your changes and push it to the repository. You can do this directly from the issue, see documentation.
2. Open a pull request (PR) from your branch to develop. Your PR should include a short description of changes and show screenshots of the changes.
3. Assign at least one reviewer.
4. The reviewer will ensure code quality, test coverage, and adherence to coding standards.
5. Once the PR is approved, merge it into develop.

Releases

When all features have been completed and are on develop a release branch will be created to prepare the production release into main.

1. Create a new branch following the release convention.
2. Merge all changes from develop
3. Thoroughly test all features on devices of different dimensions, fix any bugs found and make sure the application can be deployed on a physical device.
4. Squash and merge all changes onto main. Try to keep this branch's history as linear and clear as possible.
5. Create and tag the release on GitHub.

Versioning

• tbd

Code Reviews

• All code changes must undergo a code review before merging.
• Provide constructive feedback in reviews to ensure code quality and knowledge sharing.