Skip to Content
Git management (DRAFT)

https://miro.com/app/board/uXjVJYE7ByQ=/?share_link_id=624512481975


Git Repository Management & Deployment Workflow

1. Purpose

Define consistent procedures for managing Git repositories, supporting custom development projects, and ensuring smooth testing and deployment processes.

2. Scope

This SOP applies to all developers and project managers working on client Git repositories managed through a central project/task management tool.

3. Branching Strategy

  • live: Production-ready code deployed to the client’s live environment.
  • stage: Aggregated, QA-approved code being tested in the staging environment.
  • {task-id}-{short-description}: Task-specific branches (e.g., 452-add-discount-field).

4. Development Process

  1. Create feature branch from live: 
    git checkout live
git pull
git checkout -b feature/{task-id}-{description}
  2. Develop and commit code. Use task ID in commit messages.
  3. Push and open a Pull Request (PR) targeting stage. Link to project/task.
  4. Code review is required before merging. Assign a reviewer.

5. QA & Testing on Stage

  • After PR approval, merge feature into stage.
  • Staging environment auto/manual deployment occurs.
  • QA verifies functionality. If failed, reassign task for fixes on the same branch.
  • Once QA passes, mark task as “Ready for Production.”

6. Releasing to Live

  1. Project Manager confirms completed, QA-approved tasks.
  2. (Optional) Create a release branch from stage: release/2025-07-14
  3. Run final verification or smoke tests.
  4. Merge into live: 
    git checkout live
git merge stage
git tag -a vX.Y.Z -m "Release description"
git push origin live --tags
  5. Deploy live branch to production environment.

7. Hotfixes

  • Create branch from live: hotfix/{issue}
  • After fix, merge into both live and stage
  • Tag and deploy as needed

8. Policies

  • Only approved team members can merge to live
  • Commits and PRs must reference task IDs
  • All PRs must pass CI (if configured) before merging
  • Feature branches must be rebased (or merged) with stage before PR if stale

9. Documentation & Audit Trail

  • Update documentation as needed when features are added
  • Git and task management history serve as audit trail

https://miro.com/app/board/uXjVJYE7ByQ=/?share_link_id=624512481975