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.