7 min read By Sarah Chen

Git Workflows: Best Practices for Teams

Master Git workflows and collaboration strategies to improve team productivity and maintain a clean, organized codebase.

Git Version Control Team Collaboration DevOps
Git Workflows: Best Practices for Teams

Why Git Workflows Matter

A well-defined Git workflow helps teams collaborate effectively, maintain code quality, and ship features with confidence.

1. Feature Branch Workflow

The most common workflow for teams:

# Create feature branch from main
git checkout main
git pull origin main
git checkout -b feature/user-authentication

# Make changes and commit
git add .
git commit -m "feat: add user login functionality"

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

# Create pull request for review

Advantages:

  • Simple and straightforward
  • Each feature is isolated
  • Easy code review process
  • Main branch stays stable

2. Git Flow

A more structured approach with multiple long-lived branches:

# Main branches
main        # Production-ready code
develop     # Integration branch

# Supporting branches
feature/*   # New features
release/*   # Release preparation
hotfix/*    # Emergency fixes

Example workflow:

# Start new feature
git checkout develop
git checkout -b feature/shopping-cart

# Work on feature
git add .
git commit -m "feat: implement cart functionality"

# Merge to develop when ready
git checkout develop
git merge feature/shopping-cart
git branch -d feature/shopping-cart

# Create release branch
git checkout -b release/1.2.0
# Bug fixes only
git commit -m "fix: cart calculation error"

# Merge to main and develop
git checkout main
git merge release/1.2.0
git tag -a v1.2.0 -m "Version 1.2.0"

git checkout develop
git merge release/1.2.0

3. GitHub Flow

Simplified workflow perfect for continuous deployment:

# Everything starts from main
git checkout main
git checkout -b add-payment-integration

# Make changes
git commit -am "feat: add Stripe payment"

# Push and create PR
git push origin add-payment-integration

# After review and CI passes, merge to main
# Deploy automatically

4. GitLab Flow

Combines feature branches with environment branches:

main                # Production
pre-production      # Staging
development         # Dev environment

# Feature workflow
feature/* development pre-production main

Commit Message Best Practices

Conventional Commits

# Format: type(scope): subject

feat(auth): add OAuth login
fix(cart): resolve checkout bug
docs(readme): update installation steps
style(header): improve navigation spacing
refactor(api): simplify data fetching
test(user): add integration tests
chore(deps): update dependencies

Good vs Bad Commits

# Bad
git commit -m "fix stuff"
git commit -m "update"
git commit -m "asdfasdf"

# Good
git commit -m "fix(auth): resolve token expiration issue"
git commit -m "feat(dashboard): add analytics widgets"
git commit -m "refactor(api): extract validation middleware"

Commit Guidelines

  1. Use present tense: “add feature” not “added feature”
  2. Keep subject under 50 characters
  3. Add body for complex changes
  4. Reference issues: “Closes #123”

Example with body:

git commit -m "feat(search): implement full-text search

- Add Elasticsearch integration
- Create search API endpoint
- Add search UI component
- Update documentation

Closes #456"

Branch Naming Conventions

# Feature branches
feature/user-profile
feature/payment-integration

# Bug fixes
fix/login-redirect
fix/cart-calculation

# Hotfixes
hotfix/security-patch
hotfix/critical-bug

# Releases
release/1.2.0
release/2.0.0-beta

# Experiments
experiment/new-architecture
spike/performance-test

Pull Request Best Practices

Good PR Description

## Description
Implements user authentication using JWT tokens

## Changes
- Add login/register endpoints
- Implement JWT middleware
- Add password hashing with bcrypt
- Create auth utilities

## Testing
- [x] Unit tests pass
- [x] Integration tests pass
- [x] Manual testing completed

## Screenshots
[Add screenshots if UI changes]

## Checklist
- [x] Code follows style guidelines
- [x] Self-review completed
- [x] Documentation updated
- [x] No console warnings

Closes #123

PR Size Guidelines

# Small PR (preferred): 100-200 lines
- Single responsibility
- Easy to review
- Quick feedback cycle

# Medium PR: 200-500 lines
- Related changes
- Can be reviewed in one sitting

# Large PR: 500+ lines
- Avoid if possible
- Break into smaller PRs
- Provide detailed context

Code Review Tips

For Authors

# Before creating PR
git checkout feature/my-feature
git rebase main  # Update with latest main
git push --force-with-lease

# Self-review your changes
git diff main...feature/my-feature

# Add reviewers and labels
# Respond to feedback promptly

For Reviewers

Look for:

  1. Code quality

    • Readability and maintainability
    • Follows project conventions
    • No obvious bugs
  2. Tests

    • Adequate test coverage
    • Tests are meaningful
  3. Documentation

    • Updated docs
    • Clear comments where needed
  4. Performance

    • No performance regressions
    • Efficient algorithms

Merge Strategies

Merge Commit (Default)

git checkout main
git merge feature/new-feature

# Creates merge commit
# Preserves complete history

Squash and Merge

git checkout main
git merge --squash feature/new-feature
git commit -m "feat: add new feature"

# Combines all commits into one
# Cleaner main history

Rebase and Merge

git checkout feature/new-feature
git rebase main
git checkout main
git merge feature/new-feature

# Linear history
# No merge commits

Handling Conflicts

# Update your branch
git checkout feature/my-feature
git fetch origin
git rebase origin/main

# If conflicts occur
# 1. Fix conflicts in files
# 2. Stage resolved files
git add .

# 3. Continue rebase
git rebase --continue

# Or abort if needed
git rebase --abort

Useful Git Commands

History and Inspection

# View commit history
git log --oneline --graph --all

# Search commits
git log --grep="search term"

# Show changes in commit
git show abc123

# Who changed this line?
git blame filename.js

# Find when bug was introduced
git bisect start
git bisect bad  # Current version is bad
git bisect good abc123  # This commit was good

Undoing Changes

# Undo last commit (keep changes)
git reset --soft HEAD~1

# Undo last commit (discard changes)
git reset --hard HEAD~1

# Revert a commit (creates new commit)
git revert abc123

# Discard local changes
git checkout -- filename.js

# Restore deleted file
git checkout HEAD filename.js

Cleaning Up

# Delete merged branches
git branch --merged | grep -v "\*" | xargs -n 1 git branch -d

# Delete remote branches
git push origin --delete feature/old-feature

# Clean up references
git remote prune origin

# Remove untracked files
git clean -fd

Advanced Techniques

Interactive Rebase

# Clean up last 3 commits
git rebase -i HEAD~3

# Options:
# pick = keep commit
# reword = change commit message
# squash = combine with previous
# drop = remove commit

Cherry-Pick

# Apply specific commit to current branch
git cherry-pick abc123

Stash

# Save work in progress
git stash save "WIP: feature X"

# List stashes
git stash list

# Apply stash
git stash apply stash@{0}

# Apply and remove
git stash pop

Hooks

# pre-commit hook example
#!/bin/sh
npm run lint
npm test

Team Guidelines

Branch Protection Rules

main:
  - Require pull request reviews (2)
  - Require status checks to pass
  - Require branches to be up to date
  - Include administrators
  - Require linear history

CI/CD Integration

# .github/workflows/pr-checks.yml
name: PR Checks
on: pull_request

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm install
      - run: npm test
      - run: npm run lint

Conclusion

A solid Git workflow is essential for team productivity. Choose a workflow that fits your team size and deployment frequency, establish clear conventions, and automate as much as possible. Remember: the best workflow is one your team actually follows consistently.

S

Sarah Chen

Published on March 5, 2024

Share: