Git & GitHub

Git Workflows & Best Practices

3 min read
Focus: GIT
⚡

TL;DR — Quick Summary

  • GitHub Flow: main is always deployable, branch → PR → merge → deploy. Simple and fast.
  • GitFlow: main + develop + feature/* + release/* + hotfix/*. For scheduled versioned releases.
  • Trunk-Based: Everyone commits to main daily with feature flags. Requires strong CI/CD.
  • For most teams: start with GitHub Flow. Add complexity only when you outgrow it.

Lesson Overview

🏗️ Why Workflows Matter

Git is flexible — there's no single right way to use it. But teams that lack a shared workflow end up with chaotic histories, merge conflicts, and deployment headaches. A Git workflow is a team agreement on how branches are created, named, merged, and deleted.

🌊 GitHub Flow — Simple and Effective

Ideal for teams deploying continuously. Has only 2 permanent concepts:

  • main is always deployable
  • Every feature or fix lives on its own branch → PR → merge to main → deploy

Best for: Startups, web apps, CI/CD-heavy teams, open source.

🔀 GitFlow — Feature-Rich but Complex

Designed for software with versioned releases. Uses multiple permanent branches:

  • main — production releases only, tagged with version numbers
  • develop — integration branch for completed features
  • feature/* — individual features, branch off develop
  • release/* — release preparation, branch off develop
  • hotfix/* — emergency fixes on production, branch off main

Best for: Mobile apps, versioned products, scheduled releases.

🚀 Trunk-Based Development

Everyone commits to main (the "trunk") at least once a day. Feature flags hide incomplete work. Requires strong CI/CD and test coverage.

Best for: Google, Facebook-scale teams with mature testing infrastructure.

For most teams starting out: GitHub Flow is the sweet spot — simple enough to follow, structured enough to scale.

Conceptual Deep Dive

The real difference between workflows is answering the question: "When is code considered ready for production?" GitHub Flow says: always — if it passes review and CI, merge and deploy immediately. GitFlow says: on a schedule — accumulate features on develop, cut a release branch, test thoroughly, then ship to main. Trunk-Based says: continuously — everyone's committing to main hourly, feature flags hide unfinished work, automated tests catch issues instantly. Your choice depends on your deployment frequency, team size, and testing maturity.

Implementation Lab

GitHub Flow — Complete Daily Workflow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# === GITHUB FLOW IN PRACTICE ===
 
# Rule 1: main is ALWAYS deployable. Never break it.
# Rule 2: Create a branch for ANY change, no matter how small.
 
# Morning sync
git checkout main
git pull origin main
 
# Start work
git checkout -b feature/user-notifications
 
# Work, commit, work, commit
git commit -m "Add notification bell icon to navbar"
git commit -m "Add notification dropdown with sample data"
git commit -m "Connect notifications to API endpoint"API endpoint"
 
# Push and open PR
git push -u origin feature/user-notifications
# → GitHub: open Pull Request → describe change → link issue → request review
 
# After approval and CI green → Squash & Merge on GitHub
# Branch is deleted → main is updated → deploy triggers
 
# Pull latest main
git checkout main
git pull origin main
# main now contains your feature — live in production
GitFlow — Release and Hotfix Branches
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# === GITFLOW KEY OPERATIONS ===
 
# Feature development (branch from develop)
git checkout develop
git checkout -b feature/payment-gateway
# ... work and commit ...
git checkout develop
git merge feature/payment-gateway  # merge back to develop
git branch -d feature/payment-gateway
 
# Creating a release (branch from develop)
git checkout develop
git checkout -b release/2.1.0
# Only bugfixes allowed here — no new features
git commit -m "Bump version to 2.1.0"2.1.0"
git commit -m "Fix edge case in checkout validation"
# When ready:
git checkout main
git merge release/2.1.0
git tag -a v2.1.0 -m "Release version 2.1.0"2.1.0"
git checkout develop
git merge release/2.1.0  # sync bugfixes back to develop
git branch -d release/2.1.0
 
# Emergency hotfix on production (branch from main!)
git checkout main
git checkout -b hotfix/critical-payment-bug
git commit -m "Fix: prevent double-charge on retry"
git checkout main
git merge hotfix/critical-payment-bug
git tag -a v2.1.1 -m "Hotfix 2.1.1"2.1.1"
git checkout develop
git merge hotfix/critical-payment-bug  # don't forget develop!
git branch -d hotfix/critical-payment-bug
Useful Git Aliases for Professional Use
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Set up powerful aliases every professional uses
git config --global alias.st 'status'
git config --global alias.co 'checkout'
git config --global alias.br 'branch'
git config --global alias.graph 'log --oneline --graph --all --decorate'
git config --global alias.undo 'reset --soft HEAD~1'1'
git config --global alias.save 'stash push -m'
git config --global alias.ls 'log --oneline -20'
 
# Now use them:
git st            # git status
git graph         # beautiful commit tree
git undo          # safely uncommit last commit
git save "wip: adding payment UI"  # stash with message
git ls            # last 20 commits one-liner

Pro Tips — Senior Dev Insights

1

Set up GitHub Actions to auto-deploy to production on every merge to main — this makes GitHub Flow effortless.

2

Use git tag -a v1.2.0 -m "Release notes here" for annotated tags — they include the tagger, date, and a message, unlike lightweight tags.

3

Consider git-flow CLI tool if adopting GitFlow — it automates the branch creation and merging with single commands like git flow feature start my-feature.

4

Document your workflow as code in .github/ folder: PR templates, issue templates, and workflow YAML files — this makes onboarding new developers instant.

Common Developer Pitfalls

!

Adopting GitFlow without needing its complexity — most teams don't release on a schedule and find it heavy overhead.

!

Having a workflow on paper that nobody follows in practice — enforce it with branch protection rules.

!
Not tagging releases — git tag v1.0.0 on main gives you permanent, traceable version markers.
!

Creating a new workflow from scratch every project instead of starting with a proven one and adapting.

Interview Mastery

GitHub Flow has one simple rule: main is always deployable. The workflow: (1) pull latest main, (2) create a descriptively named branch, (3) make commits, (4) push branch and open a PR, (5) get review and pass CI, (6) merge to main, (7) deploy immediately. No staging branches, no version branches — just main and feature branches. Simple, fast, great for continuous deployment.

GitFlow is better when: (1) you have scheduled releases rather than continuous deployment (mobile apps, enterprise software), (2) you need to maintain multiple production versions simultaneously, (3) you need a dedicated integration branch to accumulate features before testing, (4) your release cycle requires a stabilization period with only bugfixes allowed. GitFlow's complexity is only worth it when you truly need it — most web teams don't.

A hotfix in GitFlow is a branch created directly from main (not develop) to fix a critical production bug. It's special because it bypasses the normal feature → develop → release → main path, allowing emergency fixes to go to production immediately. After merging to main (with a new patch version tag), it MUST also be merged back to develop so the fix isn't lost in the next release.

Real-World Blueprint

"A SaaS company with 15 developers uses GitHub Flow. Every developer works in feature branches, PRs require 1 approval and all CI checks (tests, linting, security scan) to pass. Merging to main automatically deploys to production via GitHub Actions. They ship 5-10 times per day. When a bug hits production, a hotfix branch is created, PR opened with 'priority' label, reviewed in minutes, and deployed. Total time from bug report to fix in production: under 30 minutes."

Hands-on Lab Exercises

1

Set up a sample project and simulate the GitHub Flow: create 3 feature branches, open 3 PRs (against each other or main), merge them in order.

2

Practice the complete GitFlow lifecycle: develop → feature → merge to develop → release branch → merge to main with a version tag → hotfix → merge to both main and develop.

3

Set up 5 useful Git aliases and practice using them for a week.

4
Write a CONTRIBUTING.md for a real or sample project documenting branch naming, commit message format, and PR requirements.

Real-World Practice Scenarios

Your team is building a mobile app with monthly releases and need to support the previous version while building the next. Which workflow fits best and why?

You're the sole developer on a side project that deploys to Heroku on every push to main. What's the simplest sensible workflow?

A critical security vulnerability is discovered in production. Walk through the exact Git workflow to patch it in under 30 minutes.

Two developers accidentally both created branches named feature/update-api. How does this happen and how do you prevent it?