Core Principles

• main branch is sacred: The main branch exclusively holds code that is production-ready and suitable for immediate deployment to pre-production.

• Feature Isolation: Development of new features or changes takes place in isolated feature branches.

• Pull Requests for Integration: Merging features into main is strictly controlled through pull requests (PRs), enforcing code review and quality checks.

Branching Model

1. main: The primary branch representing the latest pre-production-ready code. All merges into main trigger pre-production deployments.

2. develop: Serves as the integration branch for completed features. Code in develop should be stable but may not be fully production-ready.

3. feature/*: Short-lived branches created off develop for developing individual features or fixes. Names follow a convention like feature/new-widget.

4. fix/*: Short-lived branches created off develop for fixing bug or issues.

Workflow

1. Start a Feature:

   • Create a new branch from the latest main or whatever is your starting point:

     git checkout -b feature/my-awesome-change

2. Develop the Feature:

   • Make code changes and commit regularly to your feature branch.
   • Push your branch to the remote repository to share and back up code.

3. Create a Pull Request:

   • Once your feature is complete and tested locally:
     • Push your feature branch to the remote repository.
     • Create a PR targeting the main branch.
     • Describe your changes and the rationale behind them.

4. Code Review & Testing:

   • Collaborators review and suggest improvements.
   • Address feedback by making additional commits to your feature branch.
   • automated tests run creating temporary testing environment based on your feature branch for more thorough review.

5. Merge into main:

   • Once the PR is approved, merge the feature branch into main.
   • After the PR from branch to main is approved and merged, a deployment pipeline is automatically triggered to deploy the updated code to EED pre-production environment.

Additional Considerations

• Hotfixes: For critical production issues, create branches directly from main (e.g., hotfix/critical-bug). Merge hotfixes simultaneously back into both main (for immediate fix) and develop (to incorporate into ongoing development).

• Release Branches: For managing formal releases to production, you may introduce release branches forked from develop to harden features and prepare for production deployment.

• Versioning: Adopt a versioning scheme (e.g., Semantic Versioning) to track pre-production releases.

Tooling

• Git clients: Support pull requests and efficient branch management (e.g., GitKraken, command-line Git).

• CI/CD Pipelines: Implement automated testing and deployment to your pre-production environment, triggered by merges into main.

Advantages

• Clean release history: main maintains a well-defined history of deployable code.

• Enforced review: Changes undergo review before reaching pre-production.

• Parallel development: Multiple features can be developed in isolation.