Editing GIT Branching Guidelines

== Git Branching Guidelines ==
=== 1. General Setup ===
1.1 Production Branch (master):
The primary branch reflecting the production-ready state.
Deployment: Directly from this branch to the production server.
1.2 QA Branch (dev):
Used for staging and testing before production.
Deployment: To the sandbox server for testing.
2. Branch Protection
Protected Branches: Both master and dev.
No direct pushes allowed; changes must be made via pull requests.
Pull Requests: Require reviews and approvals from at least one developer other than the author.
3. Branching for Development
3.1 Sprint Branches:
Naming: sprint-X where X is the sprint number.
Based on: Created from dev at the start of each sprint.
3.2 Feature Branches:
Naming: Using the Jira ticket number, e.g. JIRA-123-<branchname>.
Based on: Branched off from the respective sprint-X branch.
Purpose: Development of individual features or main tickets.
Maintenance: May be maintained by one or more developers.
3.3 Subtask Branches:
Optional: Depending on the scale of subtasks and the number of developers.
Based on: Optionally branch off from the associated feature branch using the same naming convention.
4. Development Workflow
4.1 Daily Commits:
Developers must commit changes to their respective feature branches on a daily basis
4.2 Completing a Feature:
Merge completed feature branches back into the respective sprint-X branch via pull requests
4.3 Merging to QA (dev branch):
Post-development, sprint-X branches are merged into dev.
Any number of merges can be done during the lifecycle of a sprint
Requires a pull request and approval from a developer not involved in the pull request.
Approver must do code review and can approve or reject the code with relevant comments
5. QA and Bug Fixes
5.1 QA Testing:
Features merged into dev are moved to QA for testing.
5.2 Handling Bugs:
Bugs are fixed within the original feature branch and merged back into dev as described above.
6. Release Preparation
End of Sprint: Post QA approval, dev is merged into master for production deployment.
7. Hotfix Workflow
7.1 Branching for Hotfixes:
Naming: hf-JIRA-XXX-<branchname>.
Based on: Created from master.
Purpose: Immediate repairs to production issues.
7.2 Development and Testing:
Focus on quick resolution; includes thorough testing and review.
7.3 Review and Approval:
Requires pull request and approval from another developer.
7.4 Merging and Deployment:
Hotfixes are merged into master and immediately deployed.
7.5 Propagate Hotfixes:
Merge changes into dev and any active sprint-X branches to maintain consistency.