← Back to Developer Blog
💻 DeveloperMarch 6, 20268 min read

Git Workflow That Won't Drive Your Team Crazy

Merge conflicts every day? Commits like 'fix stuff'? Here's a Git workflow that actually works for teams.

By Raspib Technology Team

Git Workflow That Won't Drive Your Team Crazy

Your team's Git history looks like a crime scene.

Merge conflicts daily. Commits like "fix", "update", "asdfgh". Nobody knows what's in production.

Here's a workflow that actually works.

The Branch Strategy

Keep it simple:

main (production)
  ↓
staging (testing)
  ↓
dev (development)
  ↓
feature/user-authentication
feature/payment-integration

Rules:

  • main = production, always deployable
  • staging = testing, mirrors production
  • dev = active development
  • feature/* = individual features

Daily Workflow

Starting New Feature

# Get latest code
git checkout dev
git pull origin dev

# Create feature branch
git checkout -b feature/add-payment-gateway

# Work on feature
# ... make changes ...

# Commit often
git add .
git commit -m "feat: add Paystack integration"

# Push to remote
git push origin feature/add-payment-gateway

Finishing Feature

# Update from dev (avoid conflicts)
git checkout dev
git pull origin dev
git checkout feature/add-payment-gateway
git merge dev

# Fix any conflicts
# ... resolve conflicts ...

# Push and create PR
git push origin feature/add-payment-gateway

Create Pull Request: feature/add-payment-gatewaydev

Commit Messages That Don't Suck

Bad Commits

fix stuff
update
asdfgh
changes
final fix
final fix 2
final fix final

Useless. Nobody knows what changed.

Good Commits

feat: add Paystack payment integration
fix: resolve order calculation bug
refactor: simplify user authentication logic
docs: update API documentation
test: add payment gateway tests

Format:

type: short description

Optional longer explanation if needed

Types:

  • feat - New feature
  • fix - Bug fix
  • refactor - Code improvement
  • docs - Documentation
  • test - Tests
  • chore - Maintenance

Avoiding Merge Conflicts

1. Pull Before You Push

# Always do this before pushing
git pull origin dev

2. Small, Frequent Commits

# Bad: One huge commit after 3 days
git commit -m "add entire payment system"

# Good: Small commits throughout
git commit -m "feat: add Paystack API client"
git commit -m "feat: add payment controller"
git commit -m "feat: add payment validation"

3. Communicate

"I'm working on the payment controller."

Now teammates know to avoid that file.

Handling Merge Conflicts

When conflicts happen:

# Pull latest
git pull origin dev

# Git shows conflicts
# <<<<<<< HEAD
# Your changes
# =======
# Their changes
# >>>>>>> dev

Steps:

  1. Open conflicted files
  2. Decide what to keep
  3. Remove conflict markers
  4. Test the code
  5. Commit
git add .
git commit -m "merge: resolve conflicts from dev"

Code Review Process

Before Creating PR

# Self-review
git diff dev

# Run tests
npm test  # or php artisan test

# Check code quality
npm run lint

PR Description Template

## What Changed
- Added Paystack payment integration
- Updated order flow to handle payments

## Why
- Client requested Paystack support
- Existing payment system only supported bank transfer

## Testing
- Tested with Paystack test keys
- All existing tests pass
- Added new payment tests

## Screenshots
[Add screenshots if UI changed]

Protecting Important Branches

Branch Protection Rules

On GitHub/GitLab:

main branch:

  • Require PR reviews (2 approvals)
  • Require tests to pass
  • No direct pushes
  • No force pushes

staging branch:

  • Require PR reviews (1 approval)
  • Require tests to pass

dev branch:

  • Require tests to pass
  • Allow direct pushes (for small fixes)

Release Process

1. Feature Complete on Dev

git checkout dev
git pull origin dev
# All features merged, tested

2. Merge to Staging

git checkout staging
git pull origin staging
git merge dev
git push origin staging

Deploy to staging server. Test everything.

3. Merge to Main

git checkout main
git pull origin main
git merge staging
git tag v1.2.0
git push origin main --tags

Deploy to production.

Real Team Example

Before structured workflow:

  • Merge conflicts: Daily
  • Broken deployments: Weekly
  • Time wasted: 5 hours/week
  • Team frustration: High

After implementing workflow:

  • Merge conflicts: Rare
  • Broken deployments: None in 3 months
  • Time saved: 5 hours/week
  • Team happiness: Much better

Common Mistakes

Mistake 1: Working Directly on Main

# Don't do this
git checkout main
# make changes
git commit -m "fix"
git push origin main

Always use feature branches.

Mistake 2: Huge Commits

# Bad: 50 files changed
git add .
git commit -m "update everything"

Break into smaller, logical commits.

Mistake 3: Not Pulling Before Pushing

# This causes conflicts
git push origin dev  # Error: rejected

# Do this instead
git pull origin dev
git push origin dev

Useful Git Commands

Undo Last Commit (Keep Changes)

git reset --soft HEAD~1

Undo Last Commit (Discard Changes)

git reset --hard HEAD~1

See What Changed

git diff
git diff --staged
git diff main..dev

Stash Changes

# Save changes temporarily
git stash

# Switch branches, do other work

# Restore changes
git stash pop

Cherry-Pick Commit

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

Bottom Line

Good Git workflow prevents chaos.

Clear branches. Meaningful commits. Regular pulls. Code reviews.

Takes discipline, but saves massive time and frustration.


Need help with team workflows?

We set up development processes for Nigerian tech teams.

📞 WhatsApp: +234 708 711 0468
📧 info@raspibtech.com
📍 Lagos Island

Related:

Need Help with Your Project?

Let's discuss how Raspib Technology can help transform your business

Related Articles

Git Workflow for Teams - Best Practices Guide