As a project grows, having everyone push code without a defined workflow quickly becomes chaotic. Features collide, bugs slip into production, and deployments become stressful.
A well-defined Git branching strategy solves these problems by introducing clear responsibilities, predictable releases, and a smooth development lifecycle.
This article explains a streamlined workflow, better collaboration, and consistency in code deployment.
Branch Definitions
master:
- Represents the live production environment.
- Code merged here is ready for deployment and should be thoroughly tested.
stage:
- Represents the staging environment.
- Used for final QA testing before code is released to production.
- Code merged here should be tested and approved by QA.
develop:
- Represents the active development environment.
- Used for integrating new features, bug fixes, and ongoing development work.
- Code merged here should be reviewed and approved by peers.
Workflow Rules
Master Branch
- Purpose: Live, stable code.
- Merge Criteria:
- All PRs should pass CI/CD checks.
- PRs must be approved by the QA team.
- Code must first be merged into stage and tested.
- Release Process: Merging a PR into master automatically triggers deployment to production.
Stage Branch
- Purpose: Staging and QA testing.
- Merge Criteria:
- All PRs should pass CI/CD checks.
- Code must first be merged into develop and tested.
- PRs must be approved by the QA team.
- Release Process: Merging a PR into stage triggers deployment to the staging environment for final QA.
Develop Branch
- Purpose: Active development.
- Merge Criteria:
- All PRs should pass CI/CD checks.
- PRs must be approved by at least one peer developer.
- Code should include unit tests where applicable.
- Release Process: Merging a PR into develop allows for integration with other features and prepares for QA.
Workflow Guidelines
1. Creating a Feature Branch
Branch from develop using the following naming convention:
feature/<feature-name>
bugfix/<issue-name>
hotfix/<issue-name>Example: feature/add-login, bugfix/fix-crash, hotfix/urgent-fix
2. Pull Request to Develop
- Open a PR to merge the feature branch into develop.
- Assign at least one peer for code review.
- Ensure all automated tests and checks pass before requesting a merge.
3. Pull Request to Stage
- After merging into develop, open a PR to merge into stage.
- Notify the QA team for testing.
- Resolve any issues or bugs identified during QA testing.
4. Pull Request to Master
- Once QA approves the changes in stage, open a PR to merge into master.
- Ensure no additional issues are identified before merging.
Branch Permissions
Key Points for Developers
1. Always branch from develop.
- Use the naming conventions for clarity and consistency.
2. Ensure quality checks.
- Write unit tests.
- Run local tests before creating a PR.
- Follow coding standards.
3. Respect the PR process.
- Always assign reviewers and request approvals.
- Address feedback promptly.
- Notify the team when a PR is ready for QA or deployment.
4. Keep branches clean.
- Delete feature branches after they are merged.
- Regularly sync your local branches with the remote repository.
CI/CD Integration
- Automated checks (build, test, lint) are required for all branches.
- Deployment:
- Master: Automatically deploys to production.
- Stage: Automatically deploys to the staging environment.
- Develop: No deployment, for active development and integration.
Ref: https://medium.com/@piashcse/git-branching-strategy-a-practical-guide-for-teams-976cbe7150a5