Scaling Git: How I Unified 100+ Repositories Across Multiple Teams

Imagine walking into an organization where every team has their own way of using Git. Some teams use main/dev, others prefer master/feature, and a few teams don't use long-lived branches at all. Now imagine trying to implement CI/CD pipelines, automate releases, and onboard new developers across this chaos. This was the challenge I faced when tasked with unifying Git practices across 100+ repositories and multiple development teams.

The Problem: Git Anarchy at Scale

The Chaos We Inherited

When I joined the organization, the Git landscape was a wild west of different practices:

• Inconsistent branching models across teams
• Missing expected branches causing CI/CD failures
• Conflicting merge strategies breaking collaborators' work
• Unclear release processes leading to deployment delays
• Onboarding nightmares for new developers

The Impact on the Organization

This inconsistency wasn't just a technical debt—it was actively hurting the business:

• CI/CD pipelines failing due to missing expected branches
• Release delays because no one knew which branch was production-ready
• Developer productivity loss from constantly switching between different Git workflows
• Integration conflicts in shared environments
• Knowledge silos where each team operated in isolation

The Solution: A Unified Trunk-Based Strategy

Step 1: Analyzing the Current State

Before implementing any changes, I needed to understand the full scope of the problem.

Automated Repository Audit

# Script to analyze all repositories
#!/bin/bash
for repo in $(gh repo list --limit 1000 --json nameWithOwner -q '.[].nameWithOwner'); do
    echo "Analyzing $repo"
    gh api repos/$repo/branches --jq '.[].name' >> branch_analysis.txt
done

Key Findings:

• 47 different branching patterns across 100+ repositories
• 23 teams using completely different workflows
• 15 repositories with no clear main branch
• 8 teams rebasing public branches (breaking others' work)

Step 2: Designing the Unified Strategy

Based on the audit results, I designed a trunk-based development model that would work for all teams:

The Core Strategy

# Standardized branch structure
main          # Always production-ready
release/x.y   # For stabilization and hotfixes
feature/*     # Short-lived, rebased before merge
hotfix/*      # Emergency production fixes

The Rules

• main branch: Always deployable, protected with required reviews
• release/* branches: Cut from main for stabilization
• feature/* branches: Short-lived, rebased before merge
• No direct commits to protected branches
• Mandatory pull requests for all changes

Step 3: Implementation with Tooling and Education

Repository Templates

I created standardized repository templates with:

• Pre-configured branch protection rules
• CI/CD pipeline templates
• Documentation templates
• Git hooks for consistency

# Example branch protection configuration
name: Branch Protection
on:
  repository_dispatch:
    types: [setup-protection]

jobs:
  setup-protection:
    runs-on: ubuntu-latest
    steps:
      - name: Protect main branch
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.repos.updateBranchProtection({
              owner: context.repo.owner,
              repo: context.repo.repo,
              branch: 'main',
              required_status_checks: {
                strict: true,
                contexts: ['ci/cd-pipeline']
              },
              enforce_admins: true,
              required_pull_request_reviews: {
                required_approving_review_count: 2
              },
              restrictions: null
            })

Team Education Program

• Hands-on workshops for each team
• Best practices documentation tailored to our strategy
• Migration guides for teams with existing workflows
• Office hours for ongoing support

Step 4: Phased Rollout and Iteration

Phase 1: Early Adopters (Weeks 1-4)

• 5 teams volunteered to pilot the new strategy
• Collected feedback and refined the approach
• Created success stories and case studies

Phase 2: Department Rollout (Weeks 5-8)

• Rolled out to entire departments
• Provided dedicated support and training
• Monitored adoption metrics and addressed issues

Phase 3: Organization-Wide (Weeks 9-12)

• Mandatory adoption for all remaining teams
• Automated migration tools for complex repositories
• Final cleanup and standardization

The Results: Transformation at Scale

Quantitative Improvements

• 95%+ repository alignment within 2 months
• 60% reduction in CI/CD pipeline failures
• 40% faster release cycles
• 80% reduction in merge conflicts
• 50% faster new developer onboarding

Qualitative Improvements

• Clearer communication between teams
• Predictable release processes
• Easier cross-team collaboration
• Reduced cognitive load for developers
• Better audit trails for compliance

Lessons Learned: What Made This Successful

1. Start with Data, Not Assumptions

• Audit everything before making changes
• Measure the impact of current practices
• Use metrics to drive decision-making

2. Choose Simplicity Over Complexity

• Trunk-based development was simple enough for all teams
• Clear rules that everyone could understand
• Minimal cognitive overhead for developers

3. Invest in Tooling and Automation

• Repository templates made adoption easier
• Automated branch protection enforced consistency
• CI/CD integration validated the strategy

4. Education and Support Are Critical

• Hands-on training was essential for adoption
• Ongoing support helped teams through the transition
• Success stories motivated reluctant teams

5. Iterate Based on Feedback

• Listen to teams and adjust the strategy
• Allow exceptions during the transition period
• Continuously improve based on real-world usage

Common Pitfalls to Avoid

Pitfall 1: Mandating Without Understanding

Problem: Forcing teams to adopt a strategy without understanding their needs Solution: Start with analysis and include teams in the design process

Pitfall 2: One-Size-Fits-All Approach

Problem: Trying to force the same strategy on all teams regardless of their context Solution: Allow for variations while maintaining core principles

Pitfall 3: Lack of Tooling Support

Problem: Expecting teams to manually implement complex strategies Solution: Provide templates, automation, and tooling to make adoption easy

Pitfall 4: Insufficient Training and Support

Problem: Assuming teams will figure out the new strategy on their own Solution: Invest heavily in education, training, and ongoing support

The Long-Term Impact

For Development Teams

• Consistent workflows across all projects
• Reduced learning curve when switching between projects
• Better collaboration with other teams
• Clearer processes for releases and deployments

For the Organization

• Improved delivery velocity through standardized processes
• Reduced operational overhead from consistent tooling
• Better compliance through standardized audit trails
• Easier scaling as the organization grows

For New Developers

• Faster onboarding with consistent practices
• Clear expectations about Git workflows
• Better mentorship opportunities
• Reduced confusion about different team practices

Conclusion

Unifying Git practices across a large organization is not just a technical challenge—it's a change management challenge that requires careful planning, strong leadership, and persistent execution. The key to success is:

• Start with data to understand the current state
• Choose a simple, scalable strategy that works for all teams
• Invest in tooling and automation to make adoption easy
• Provide education and support throughout the transition
• Iterate based on feedback and real-world usage

Related Topics

• Git Branching Strategy: Best Practices
• Three Common Git Challenges Every Developer Faces
• Git Merge vs Rebase: Understanding the Key Differences
• Git Fetch vs Pull: Understanding the Key Differences