Git Workflow

Our Git Workflow defines the steps and best practices for collaboration on the bounswe2025group3 project. Following this workflow ensures a consistent development process, a clean commit history, and smooth integration of new features and fixes into the main codebase.

1. Branching Model

• Feature Branches:
  For every new feature, bug fix, or improvement, create a dedicated branch off the main branch. This isolates your work from the production code and allows for independent testing.

  • Naming Convention: Use descriptive names with prefixes such as feature/, fix/, or hotfix/.
    • Examples:
      • feature/user-authentication
      • fix/login-bug

• Main Branches:

  • main (or master): Contains production-ready code.
  • develop: (If used) Serves as the integration branch for feature branches before releasing to production.

2. Commit Guidelines

• Atomic Commits:
  Each commit should represent a single logical change. This makes it easier to understand the history and helps in isolating issues.

• Clear Commit Messages:

  • The first line should be a short summary (ideally less than 50 characters).
  • Follow with a blank line and a more detailed explanation if needed.
  • Use the present tense and imperative mood (e.g., “Add login authentication with JWT”).

• Example Commit Message Format:

  Add user authentication via JWT
  
  This commit includes authentication middleware and updates the login API to support JWT-based authentication.
  

3. Pull Requests and Code Reviews

• Creating Pull Requests (PRs):
  When a branch is ready, push it to the remote repository and create a pull request. The PR should:

  • Clearly describe the purpose of the changes.
  • Reference any related issues or tickets.
  • Include context that would help reviewers understand the code.

• Review Process:

  • At least one team member should review the PR.
  • Check for code quality, adherence to project standards, and appropriate test coverage.
  • Address all feedback and perform any required adjustments before merging.

4. Merging Strategy

• Merge Method:

  • Squash and Merge: Consolidates all the commits from a branch into one before merging into the main branch, keeping the history clean.
  • Rebase and Merge: Alternatively, maintain a linear history by rebasing your feature branch onto the latest main branch (if preferred by the team).

• Conflict Resolution:

  • Always pull the latest changes from the target branch before merging.
  • Resolve any merge conflicts locally and ensure that all tests pass.

• Post-Merge:
  After merging, delete the feature branch from the remote repository to keep the branch list manageable.

5. Tagging and Releases

• Version Tagging:
  When preparing a release, create annotated tags on the main branch following semantic versioning (e.g., v1.0.0).

• Release Branches:
  If necessary, use a release branch to perform final testing and stabilization before tagging a new version.

6. Best Practices

• Consistency:
  Maintain uniformity in branch naming, commit messages, and PR descriptions.

• Communication:
  Clearly document the purpose and context of changes in commit messages and PRs.

• Continuous Integration (CI):
  Ensure all tests pass in your CI pipeline before merging any code.

• Documentation:
  Keep the project wiki and other documentation updated with any changes to the workflow or project structure.