Skip to content

Git Workflow Documentation

Jump to bottom
Mai edited this page Feb 27, 2025 · 2 revisions

Overview

This document outlines the branching strategy for our development workflow using Git. Following this strategy ensures smooth collaboration and a structured release process.

Git Flow Process

1. Create a GitHub Issue

  • Every new feature, enhancement, or bug fix should start with a GitHub Issue.
  • The issue should follow the provided issue template and include a clear description, acceptance criteria, and any relevant details.

2. Create a Feature Branch from develop

  • Name the branch using the issue number and a short description (e.g., feature/42-add-login-auth).
  • This branch captures all the work related to the GitHub Issue.
  • Push the branch to the remote repository.

3. Develop and Commit Code

  • Regularly commit code to the feature branch with meaningful commit messages. An example of a good commit message would be: Fix flaky login test by stabilizing wait conditions
  • If develop has any infra changes or changes to the files you're altering, ensure the branch stays up to date by pulling the latest changes from develop (see “Keeping your feature branch up to date”).
  • Run tests and verify functionality before creating a PR.

4. Create a Pull Request (PR) to Merge Feature Branch into develop

  • Once work is completed and tested, create a PR to merge the feature branch into develop.
  • If your PR is not ready to be reviewed, please mark it as a “draft”.
  • Use the PR template to document changes and ensure all acceptance criteria are met.
  • Request reviews from at least two team members, including at least one member of the core website team.
  • Address feedback and make necessary changes.

You can find the Pull Request Template Here

5. Merge Feature Branch into develop

  • After approval from all reviewers, merge the feature branch into develop.
  • If you can’t merge your own branch, please contact Daaimah or Kaylah to have your permissions fixed.
  • Delete the feature branch after merging to keep the repository clean.

6. Weekly Merge from develop to main

  • Once a week, a PR is created to merge all completed features from develop into main.
  • The PR should summarize all included changes and be reviewed by all reviewers, typically at least one staff member, one cohort member and your mentor.
  • After approval, merge develop into main.

7. Create a GitHub Release

  • Once develop is merged into main, a GitHub release should be created by Techtonica staff.
  • The release should include a version number (e.g., v1.0.0) and a summary of changes.
  • This serves as a record of what was released in production.

8. Deploy to Staging Server

  • After merging into main, the latest version is deployed to the staging server.
  • Test the release to ensure everything works as expected.

9. Deploy to Production Server

  • After successful verification on staging, the release is deployed to the production server.
  • Final testing is performed to confirm everything is functioning correctly in production.
    • TODO: Who performs final testing, what does testing entail

More information on Git Flow here.

Clone this wiki locally