Git Advanced Workflows for Teams: Mastering Collaboration at Scale

Git has become the de-facto standard tool for version control. Knowing the basic Git commands is just the starting point for almost everyone using Git. Adopting an advanced Git workflow brings several advantages: better code quality, easier merges, and easier distributed teams collaboration. In this blog post, we’ll look at some of the most advanced Git workflows adopted by the largest engineering teams in the world.

Why Workflow Matters in Team Environments

I think open source projects, especially those that grow in size, can quickly devolve into complete chaos. Many people will chime in and make feature requests and bug reports without really thinking about whether their ideas will improve the overall project. And without anyone at the helm to dictate what should be prioritized, these projects can really fall apart. Using Git to manage the workflow can really help to stave off chaos.

• Clear communication channels for code changes
• Conflict prevention and resolution mechanisms
• Code quality assurance through structured review processes
• Release management and versioning consistency
• Traceability of changes and accountability
• Risk mitigation by controlling what gets deployed

How many people are on your team? What is your current release schedule like? What does your organizational structure look like? We’ll work with you to choose the best workflow for your use case.

Git Flow: The Comprehensive Model

I suppose most people have at least two production ready releases for their application which get deployed to different environments. Git Flow by Vincent Driessen is a very popular read on managing multiple production ready releases for an application.

Git Flow Structure

Git Flow uses multiple long-lived branches:

• main: Production-ready code only
• develop: Integration branch for features
• feature branches: Individual feature development
• release branches: Release preparation
• hotfix branches: Production bug fixes

Workflow Example

bash

Start a new feature

git flow feature start awesome-feature

Work on your feature

git add .
git commit -m "Add awesome feature"

Finish the feature (merges to develop)

git flow feature finish awesome-feature

Create a release

git flow release start 1.2.0

Update version numbers, changelog

git flow release finish 1.2.0

Handle production hotfixes

git flow hotfix start 1.2.1
git flow hotfix finish 1.2.1

When to Use Git Flow

• Multiple versions in production simultaneously
• Scheduled release cycles
• Large teams with specialized roles
• Projects requiring extensive release planning
• Compliance and audit requirements

Advantages and Disadvantages

Advantages:

• Clear separation of concerns
• Excellent for managing multiple releases
• Well-documented and widely understood
• Supports parallel development

Disadvantages:

• Complex with many branches to manage
• Can slow down deployment cycles
• Merge conflicts more likely
• Steep learning curve for new team members

GitHub Flow: Simple and Effective

The GitHub Flow methodology is promoted by GitHub themselves and is a more lightweight approach that is well suited to the continuous deployment style of deployment.

GitHub Flow Principles

1. Create a descriptive branch from main
2. Make commits with clear messages
3. Open a pull request for discussion
4. Review and discuss the implementation
5. Deploy for final testing
6. Merge when ready
7. Deploy to production

Implementation Example

bash

Create and switch to a feature branch

git checkout -b fix/user-authentication

Make your changes

git add src/auth.js
git commit -m "Fix: Improve JWT token validation"

Push to remote

git push origin fix/user-authentication

Create pull request on GitHub

After approval and CI passes:

git checkout main
git pull origin main
git merge fix/user-authentication
git push origin main

Cleanup

git branch -d fix/user-authentication

When to Use GitHub Flow

• Continuous deployment practices
• Rapid release cycles
• Small to medium teams
• Cloud-native applications
• DevOps-focused organizations

Key Advantages

• Minimal branch complexity
• Fast feedback cycles
• Supports continuous deployment
• Easy to understand and teach
• Reduces merge conflicts

Trunk-Based Development: Extreme Simplicity

Last week I explained the idea of using a minimalistic branching model on top of Trunk-Based Development (TBD) as a way to include a couple of advanced features. This week, I will explore this idea further, and I will comment on the “minimalism” of TBD that sometimes goes a bit too far in the minimal direction. If you haven’t read last week’s post, here is a quick catch up on what TBD is. In Trunk-Based Development (TBD) all the features are merged directly into the main/trunk branch of the repository, and occasionally, very short-lived, feature/bugfix/changesets branches might be needed.

TBD Principles

• Main branch is always deployable
• Feature flags for incomplete features
• Developers commit to main daily
• Continuous integration is mandatory
• Automated testing gates all commits

Feature Flags Implementation

javascript
// Implementation with feature flags
function getUserProfile(userId) {
if (isFeatureEnabled('new-profile-ui', userId)) {
return getNewProfileUI(userId);
}
return getLegacyProfileUI(userId);
}

// Configuration
const featureFlags = {
'new-profile-ui': {
enabled: false,
rolloutPercentage: 10,
targetUsers: ['beta-testers']
}
};

When to Use TBD

• High-performing teams with strong testing
• Microservices architectures
• Feature-flag infrastructure in place
• Organizations practicing continuous deployment
• Small, co-located or highly synchronized teams

Requirements for Success

• Comprehensive automated test coverage (>80%)
• Robust CI/CD pipeline
• Feature flag management system
• Strong discipline and communication
• Rapid deployment capability

GitLab Flow: The Balanced Approach

GitLab Flow is a software development process methodology that combines the simplicity of the GitHub Flow and the robustness of the Git Flow with environment branches. It is the recommended way of merging your code into GitLab. The underlying idea of the GitLab Flow is that all merge requests should always be merged into default branch.

GitLab Flow Branches

• main: Always deployable
• pre-production: Staging environment
• production: Production environment
• feature branches: Short-lived feature work

Production Deployment Example

bash

Feature development

git checkout -b feature/new-dashboard

... work and commit ...

git push origin feature/new-dashboard

After merge to main, automatic deployment to staging

Create merge request from main to pre-production

git checkout pre-production
git pull origin pre-production
git merge main
git push origin pre-production

When ready for production

git checkout production
git merge pre-production
git push origin production
git tag v1.5.0

When to Use GitLab Flow

• Organizations requiring environment promotion
• Teams wanting controlled rollout
• Projects with separate staging environments
• Companies using GitLab CI/CD

Choosing the Right Workflow for Your Team

Decision Matrix

Feature & Release Branching Model Feature & Release Branching Model | Feature & Release Branching Model
|--------|----------|-------------|-----|-------------|
| Team Size | Large | Small-Medium | Medium-Large | Medium-Large |
| Release Frequency | Scheduled | Continuous | Continuous | Scheduled |
| Complexity | High | Low | High | Medium |
| Learning Curve | Steep | Gentle | Steep | Medium |
| CI/CD Maturity | Medium | High | Critical | High |

Implementation Checklist

• Document your chosen workflow
• Create branch naming conventions
• Establish code review standards
• Configure branch protection rules
• Set up automated testing and deployment
• Train team members
• Create runbooks for common scenarios
• Monitor and iterate based on feedback

Best Practices Across All Workflows

Commit Message Standards

Follow conventional commits format:

():