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