Rehman Farouq

Full Stack Developer | Git Expert

Introduction to Git Workflows

A Git workflow defines how your team uses Git to collaborate on code. Choosing the right workflow is crucial for maintaining code quality, enabling smooth releases, and supporting team collaboration.

This guide covers the most popular Git workflows and helps you choose the right one for your team.

Feature Branch Workflow

The feature branch workflow is simple and effective for teams of all sizes. Each feature gets its own branch.

# Create a new feature branch
git checkout -b feature/user-authentication

# Make changes and commit
git add .
git commit -m "Add user authentication"

# Push to remote
git push origin feature/user-authentication

# Create pull request
# Review and merge

# Delete branch after merge
git branch -d feature/user-authentication
git push origin --delete feature/user-authentication

# Update main branch
git checkout main
git pull origin main

# Branch naming conventions
feature/feature-name
bugfix/bug-description
hotfix/critical-fix
release/version-number
docs/documentation-update
refactor/code-refactoring
test/add-tests

Best Practices

•Keep branches focused and short-lived
•Use descriptive commit messages
•Always pull before pushing
•Require code reviews for all merges

GitFlow Workflow

GitFlow is a strict branching model designed for projects with scheduled release cycles.

# GitFlow branches
# main - production code
# develop - integration branch
# feature/* - new features
# release/* - release preparation
# hotfix/* - production fixes

# Initialize GitFlow
git flow init

# Start a new feature
git flow feature start user-authentication

# Finish feature (merge to develop)
git flow feature finish user-authentication

# Start a release
git flow release start v1.0.0

# Finish release (merge to main and develop)
git flow release finish v1.0.0

# Start a hotfix
git flow hotfix fix-critical-bug

# Finish hotfix
git flow hotfix finish fix-critical-bug

# Branch structure
main (production)
  ├── v1.0.0
  └── v1.1.0

develop (integration)
  ├── feature/user-auth
  ├── feature/payment
  └── release/v1.0.0

feature/* (new features)
  ├── feature/user-auth
  └── feature/payment

release/* (release preparation)
  └── release/v1.0.0

hotfix/* (production fixes)
  └── hotfix/critical-bug

When to Use GitFlow

Pros

• Clear separation of concerns
• Structured release process
• Easy hotfix management
• Good for scheduled releases

Cons

• Complex branch structure
• More merge conflicts
• Slower development cycle
• Overkill for small teams

Trunk-Based Development

Trunk-based development is a modern approach where developers work directly on the main branch with short-lived feature branches.

# Trunk-based workflow
# Create short-lived feature branch
git checkout -b feature/auth

# Make small, frequent commits
git add .
git commit -m "Add auth service"

# Push frequently
git push origin feature/auth

# Create pull request immediately
# Continuous integration runs tests

# Merge to main after approval
# Delete branch

# Repeat for each feature

# Feature flags for gradual rollout
const featureFlags = {
  NEW_AUTH: process.env.FEATURE_NEW_AUTH === 'true',
  PAYMENT_GATEWAY: process.env.FEATURE_PAYMENT === 'true'
}

if (featureFlags.NEW_AUTH) {
  // New authentication logic
} else {
  // Old authentication logic
}

# Branch protection rules
# - Require pull request
# - Require status checks
# - Require code owner review
# - Limit who can push to main
# - Enforce linear history

Trunk-Based Best Practices

•Keep branches under 2 days
•Use feature flags for new features
•Implement comprehensive CI/CD
•Automated testing is mandatory

Commit Message Conventions

Follow commit message conventions for better collaboration and automated changelog generation.

# Conventional Commits format
<type>(<scope>): <subject>

<body>

<footer>

# Types
feat:     New feature
fix:      Bug fix
docs:     Documentation changes
style:    Code style changes (formatting)
refactor: Code refactoring
perf:     Performance improvements
test:     Adding or updating tests
chore:    Maintenance tasks
ci:       CI/CD changes
build:    Build system changes
revert:   Revert a previous commit

# Examples
feat(auth): add user authentication
fix(api): resolve timeout issue in user endpoint
docs(readme): update installation instructions
style(button): fix linting errors
refactor(user): simplify user service
perf(image): optimize image loading
test(auth): add unit tests for auth service
chore(deps): update dependencies

# Breaking changes
feat(api)!: remove deprecated endpoint

# Detailed commit
feat(auth): add OAuth2 authentication

Add support for OAuth2 authentication with Google and GitHub providers.
This includes new middleware, controllers, and database schema updates.

Closes #123

Git Hooks for Automation

Automate workflows with Git hooks to enforce standards and improve code quality.

# Pre-commit hook (.git/hooks/pre-commit)
#!/bin/bash
# Run linter before commit
npm run lint

# Pre-push hook (.git/hooks/pre-push)
#!/bin/bash
# Run tests before push
npm test

# Commit message hook (.git/hooks/commit-msg)
#!/bin/bash
# Validate commit message format
commit_regex='^(feat|fix|docs|style|refactor|perf|test|chore|ci|build|revert)((.+))?: .{1,50}'
if ! grep -qE "$commit_regex" "$1"; then
    echo "Invalid commit message format"
    exit 1
fi

# Using Husky for Git hooks
npm install husky --save-dev
npx husky install
npx husky add .husky/pre-commit "npm test"

# Using lint-staged with Husky
npm install lint-staged --save-dev

# package.json
{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,md}": [
      "prettier --write"
    ]
  }
}

# .husky/pre-commit
npx lint-staged

Branch Protection Rules

Implement branch protection to maintain code quality and prevent accidental changes.

# GitHub Branch Protection Settings
# Settings > Branches > Add rule

# Rule: main branch
✓ Require pull request before merging
  - Require approvals: 1
  - Dismiss stale reviews
  - Require review from code owners
  - Require approval for apps

✓ Require status checks to pass
  - CI/CD pipeline
  - Code coverage
  - Security scans

✓ Require branches to be up to date
✓ Do not allow bypassing the settings
✓ Restrict who can push
✓ Require linear history
✓ Allow force pushes (disabled)
✓ Allow deletions (disabled)

# Using GitHub API for branch protection
curl -X PUT \
  -H "Authorization: token YOUR_TOKEN" \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/owner/repo/branches/main/protection \
  -d '{
    "required_status_checks": {
      "strict": true,
      "contexts": ["ci/circleci"]
    },
    "enforce_admins": true,
    "required_pull_request_reviews": {
      "required_approving_review_count": 1
    },
    "restrictions": null
  }'

Git Workflow Best Practices

Collaboration

• Use descriptive branch names
• Write clear commit messages
• Review code thoroughly
• Communicate changes early

Quality

• Implement automated testing
• Use code review requirements
• Enable branch protection
• Run CI/CD on every push

Workflow

• Keep branches short-lived
• Pull frequently
• Resolve conflicts early
• Delete merged branches

Automation

• Use Git hooks
• Automate changelog
• Enable semantic versioning
• Automate releases

Conclusion

Choosing the right Git workflow depends on your team size, release cycle, and project requirements. Feature branch workflow is great for most teams, GitFlow for scheduled releases, and trunk-based for continuous delivery.

Whatever workflow you choose, consistency and automation are key to success. Implement proper branch protection, automated testing, and clear communication guidelines.

Ready to Improve Your Git Workflow?

Explore more development tutorials and streamline your team collaboration!

Git Workflows 2026: Master Version Control