Traffic-Management

Version Control and Development Workflow

Git Branch Structure

Our Git repository is organized with three primary branches:

We have adopted a rebase policy to maintain a clean and linear project history. When working on the dev branch, instead of merging changes from main, we use interactive rebasing to integrate the latest changes. This keeps the commit history streamlined and avoids unnecessary merge commits.

Git Commit Verification

All commits in our repository are verified using GPG signatures. This ensures the authenticity of the commits and helps maintain the integrity of the project history. The GPG signature is generated by adding a secret key to GitHub Secrets, adding an extra layer of security to our commits.

Branch Policy

To control the flow of changes into the main branch, we have implemented a policy. Direct pushes to the main branch are restricted. Developers are required to create a feature branch from dev, develop the feature, and then submit a pull request.

Pull Request and Code Review

Our development workflow includes the following steps:

  1. Developers create a feature branch from dev for new features or bug fixes.
  2. After completing the development, developers submit a pull request.
  3. Pull requests require approval from at least two reviewers, considering our group size of three members.
  4. Once the pull request is approved, it can be rebased into the dev branch.
  5. Thereafter, once the rebase is done and has been verified, the feature branch is deleted.

This approach ensures that changes are thoroughly reviewed before integration, maintaining code quality and consistency.

Conventional Commits

We adhere to the conventional commits specification for our commit messages. This convention helps in tracking the progress of the project more efficiently and facilitates automated versioning and changelog generation.

Go Back. Go Next.