The East Agile Git Branching Model: Engineering Excellence Through Disciplined Version Control

In today's fast-paced software development landscape, maintaining code quality while delivering features rapidly is a constant challenge. At East Agile, we've developed a robust Git branching strategy that ensures our development process remains streamlined, collaborative, and production-ready at all times. Here's an inside look at how we maintain engineering excellence through our disciplined version control practices.

Core Principles: Always Deployable, Always Green

The foundation of our Git workflow rests on one fundamental principle: our main branch is sacred. This means:

• The main branch must be deployable at any moment without exception
• CircleCI continuous integration checks must be consistently green on the main branch
• Every code change is thoroughly vetted before reaching production

This approach gives us confidence that we can deploy to production at a moment's notice, reducing risk and enabling rapid response to critical business needs.

Our Branching Workflow in Detail

1. Feature Development on Dedicated Branches

All development at East Agile begins by branching from main:

git checkout main
git pull origin main
git checkout -b feature/new-awesome-functionality

This ensures every new feature, bugfix, or enhancement starts from the most current, stable codebase. Developers work in isolation without affecting the main codebase until their changes are proven ready.

2. Pull Request Process

When a feature is complete, we create a pull request (PR) targeting the main branch. This initiates our quality control process:

• Code undergoes peer review for logic, style, and best practices
• Automated tests run via CircleCI to verify functionality
• Documentation and code clarity are assessed

The PR provides a dedicated space for discussion and improvement before any code reaches our main branch.

3. Staging Verification

Here's where our process demonstrates its rigor:

git checkout staging
git pull origin staging
git merge feature/new-awesome-functionality
git push origin staging

Before merging to main, developers must:

1. Merge their work to the staging branch
2. Deploy to our Heroku staging environment
3. Address any merge conflicts in staging (a preview of potential conflicts with main)
4. Coordinate with team members if conflicts arise with other in-progress work

Important: We strictly prohibit force-pushing to staging (git push --force) as this disrupts the work of other team members and damages our collaborative environment.

4. Product Owner Approval

Our process incorporates business validation through product owner approval:

• Features must be verified on staging by the product owner
• The associated Pivotal Tracker story must be accepted
• CircleCI must show green on the pull request

Only when all these conditions are met does a feature qualify for merging to main.

5. Merging to Main and Cleanup

Upon approval, we complete the process:

git checkout main
git pull origin main
git merge feature/new-awesome-functionality
git push origin main
git branch -d feature/new-awesome-functionality
git push origin --delete feature/new-awesome-functionality

We enforce branch cleanup after merging to maintain repository hygiene and make it clear which work is complete versus in-progress.

Staging as a Collaborative Showcase

A key advantage of our model is the ability to demonstrate multiple features simultaneously:

• The staging branch can contain multiple work-in-progress features
• Multiple developers can demo their work to stakeholders concurrently
• This accelerates feedback cycles without compromising main branch stability

Production Deployments on Our Schedule

Unlike some models that automatically deploy to production, we maintain control over when we promote code to production:

# When ready for production deployment
git checkout production
git pull origin production
git merge main
git push origin production

This gives us flexibility to coordinate releases with marketing efforts, business needs, and user expectations.

Maintaining Staging-Main Synchronization

After deploying to production, we ensure staging remains in sync with main:

git checkout staging
git pull origin staging
git merge main
git push origin staging

This critical step ensures our staging environment always contains at minimum the code currently running in production, preventing confusion and inconsistent testing environments.

Why This Matters

Our Git workflow is more than just a technical process -- it's a reflection of our engineering values:

• Quality: We prevent defects from reaching production through multiple validation steps
• Collaboration: Our workflow encourages communication and teamwork
• Confidence: The team can move quickly knowing our safety nets will catch issues
• Flexibility: We balance rapid development with controlled releases

By adhering to this disciplined branching strategy, East Agile delivers software that meets the highest standards of quality while maintaining the agility to respond to changing requirements.

At East Agile, rigorous software engineering practices like our Git branching model are part of our commitment to excellence. Our processes combine industry best practices with lessons learned from years of successful project delivery.