Skip to Content
IntroductionSource ControlWorkflow

Workflow

How we use git to collaborate on code.

Our development workflow is designed to ensure collaboration, maintain code quality, and streamline the integration of new features and fixes. We follow a Git-based workflow that emphasizes branch isolation, code quality checks, and a clear process for merging code into the main branch.

Git Workflow

Branching strategy

  • Main Branch: We utilize the main branch as our primary branch, representing the production-ready codebase. It always reflects the latest stable release of our software.

  • No dev branch: Unlike some Git workflows that include a dev or development branch, we prefer not to use one. This simplifies our workflow and reduces unnecessary branching.

  • Feature Branch: Developers branch out from main to create feature branches for their work. Each developer is responsible for their own feature branch. This approach allows developers to work independently on specific features or bug fixes without affecting the stability of the main branch.

  • Rebasing: Before merging a feature branch into main, developers are required to rebase their branch onto the latest changes from main. This involves incorporating the changes from main into your feature branch, ensuring a linear and clean commit history. It’s important not to directly merge main into your feature branch; instead, use the rebase command to synchronize your branch with the latest changes on main. This helps in maintaining a more straightforward and chronological commit history.

Pull Request Process

  1. Developers create a feature branch from main to work on their changes.
  2. When ready, developers create a PR to merge their changes into main.
  3. PRs must pass a series of checks before they can be merged into main. This includes code quality checks, automated tests, manual tests, and more.
  4. Once a PR passes all checks and receives approval, it can be merged into main.

Pull request best practices

  • Pushing directly to the main branch is restricted to maintain code stability and quality.
  • “Squash and Merge” is the preferred merge strategy. This keeps our commit history clean and linear.
  • Every PR must be associated with a JIRA issue. This allows us to track the status of each issue and ensure that all changes are documented.
  • Every PR must include a description of the changes, screenshots or videos of the changes, and a list of the affected modules. You can use the PR template below to ensure that all PRs include the necessary information.
  • Every PR must undergo CI checks to ensure code quality and prevent issues from slipping into the main branch. This includes linting, type checking, testing, and code coverage.
  • Every PR must be reviewed and approved by at least one other developer before it can be merged into main.
  • Every PR must be manually tested by the developer and/or QA team before it can be merged into main.
  • Ensure that the PR has no conflicts with the latest changes in the main branch before merging.
  • Provide context on the problem being solved and the solution chosen in the PR description.
  • Include any relevant links or references to documentation, design documents, or related discussions.
  • If the PR introduces new features or changes existing functionality, update relevant documentation.
  • Resolve all discussions and comments in the PR before merging to maintain clarity and address concerns.

Continous Integration Checks

To ensure code quality and prevent issues from slipping into the main branch, every PR must pass the following checks before it can be merged:

  1. Linting: We run linters to ensure that the code adheres to our coding standards and best practices.

  2. Tests: All tests must pass to verify that the code functions correctly and as expected.

  3. Code Coverage: We maintain a code coverage threshold of at least 80% to ensure comprehensive test coverage.

  4. Approval: A minimum of one other developer must review and approve the PR to ensure code quality and alignment with project goals.

Pull Request Template

Here’s the PR template we use to ensure that all PRs include the necessary information:

# Description
 
{{Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.}}
 
Fixes #(JIRA issue number eg PUF-1944).
 
## Type of change
 
Please delete options that are not relevant.
 
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to
      not work as expected)
 
## Screenshots or Videos
 
**Please include screenshots or videos of the changes.**
 
## Effected Areas
 
**List of effected modules.**
 
- [ ] Module 1
- [ ] Module 2
 
# Checklist:
 
- [ ] I have completed functionality tests and everything is working as expected
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings (ESLint etc.)
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream modules
- [ ] My code follows the style guidelines of this project
TestingConventions