Skip to content

Git Branching & Deployment Workflow

Overview

This document defines the workflow for managing our Git repository, ensuring a structured and controlled development process. It outlines the branching strategy, code review process, and deployment pipeline for our three main branches: development, staging, and production.

Branching Strategy

Our repository follows a structured branching model consisting of:

  • Production Branch (production) - The live, stable version of our application.
  • Staging Branch (staging) - A pre-production environment for final Quality Assurance (QA).
  • Development Branch (development) - The primary working branch for active development.

Feature Branches

All new work must be done in a feature branch. The naming convention for feature branches is:

feature/([ClickUp ID])-[ClickUp Task Name]

Example: feature/(1234)-add-user-authentication

Each feature branch should be created from the development branch.

Development Workflow

1. Create a Feature Branch

  • Developers must create a new feature branch from the development branch.
  • The branch should follow the naming convention: feature/[ClickUp ID]-[ClickUp Task Name].

2. Development & Commit Guidelines

  • Work should be committed frequently with meaningful commit messages.
  • Each commit message should reference the ClickUp task ID where possible.

Example commit message: feat(1234): Added user authentication logic

3. Push & Open a Pull Request (PR)

  • When the feature is completed, push the branch to the remote repository.
  • Open a Pull Request (PR) against the development branch for review.

4. Code Review & Approval

  • The PR must be reviewed by either Joshua or Eric.
  • Reviewers should check for code quality, adherence to best practices, and functionality.
  • If changes are required, the reviewer must address them before approval.

5. Merging the Feature Branch

  • Once the PR is approved, the feature branch will be merged into development.
  • After merging, the feature branch must be deleted from the remote repository.

Staging Deployment & QA

1. Preparing for Staging

  • Once the development branch has accumulated enough changes for testing, a PR from development to staging will be created.
  • The PR will be reviewed before merging to ensure stability.

2. Testing in Staging

  • After merging, the latest changes will be deployed to the staging environment.
  • The QA team will conduct final tests to validate functionality.
  • Any bugs or issues must be resolved in a new feature branch before proceeding.

Production Deployment

1. Final Review

  • Once all QA is completed and the staging branch is verified, a PR from staging to production will be created.
  • The PR must be reviewed for final approval.

2. Deploy to Production

  • After approval, the PR will be merged and the latest changes will be deployed to production.
  • Any post-deployment checks will be conducted to ensure stability.

Additional Guidelines

Hotfixes

Urgent fixes should be created as a new branch from production, tested, and then merged back into staging and development to maintain consistency.

Feature Flags

Major features should be developed using feature flags to prevent untested features from affecting production.

Automated Testing

Ensure all changes pass automated tests before merging into staging or production.

Summary of Workflow

1. Development Phase

  • Create feature branch from development
  • Develop, commit, and push code
  • Open PR to development
  • Code review and approval
  • Merge PR and delete feature branch

2. Staging Phase

  • Merge development → staging
  • Deploy and conduct QA testing
  • Address issues and repeat as needed

3. Production Phase

  • Merge staging → production
  • Deploy live
  • Monitor and address any post-deployment issues