Semantic Versioning Explained: MAJOR.MINOR.PATCH, Ranges, and Bump Workflows
Master SemVer for libraries and apps — pre-releases, caret vs tilde ranges, breaking-change discipline, and a release workflow that keeps dependents sane.
A practical guide to Git for frontend developers — branching strategies, commit conventions, pull request workflows, and the commands you'll use daily on product teams.
By codefunc
Git is version control. It tracks changes to files over time, lets multiple developers work on the same codebase, and provides a history you can search, blame, bisect, and revert. For frontend teams, Git is where code review happens, where CI runs, and where the record of every shipped feature lives. Understanding Git workflow — not just commands — is what makes collaboration smooth.
Bottom line: Commit small, commit often. Branch for features. Rebase or merge consistently. Write commit messages that explain why, not just what. Pull requests are conversations, not just merge gates. A clean Git history is documentation that never goes stale.
| State | Location | Description |
|---|---|---|
| Working directory | Your files | Current edits, untracked changes |
| Staging area | Index | Changes ready to commit |
| Repository | .git folder | Committed history |
# See current state
git status
# Move changes through states
git add file.tsx # working → staging
git commit -m "message" # staging → repository
git push origin branch # local repo → remote repo
| Command | Purpose |
|---|---|
git clone <url> |
Copy remote repo locally |
git pull |
Fetch and merge remote changes |
git push |
Upload local commits to remote |
git branch |
List, create, delete branches |
git checkout / git switch |
Switch branches |
git merge |
Combine branches |
git rebase |
Replay commits on new base |
git stash |
Temporarily save uncommitted changes |
git log |
View commit history |
git diff |
Compare changes |
The most common pattern for product teams:
main (production)
└── feature/add-json-formatter
└── feature/update-header-nav
└── fix/contrast-checker-edge-case
main# Create and switch to new branch
git checkout -b feature/add-json-formatter
# Or with git switch (newer)
git switch -c feature/add-json-formatter
| Prefix | Use for |
|---|---|
feature/ |
New functionality |
fix/ |
Bug fixes |
refactor/ |
Code restructuring |
docs/ |
Documentation changes |
chore/ |
Build, config, tooling |
test/ |
Test additions or fixes |
Include ticket numbers when your team uses them:
feature/PROJ-123-user-auth
fix/PROJ-456-mobile-nav-overflow
For teams that ship continuously:
main is always deployable# Short-lived branch
git checkout -b feature/button-variant
# ... small change ...
git push -u origin feature/button-variant
# ... open PR, review, merge same day ...
Longer release cycles with develop, release/*, hotfix/* branches. Adds ceremony. Most web teams have moved to simpler patterns with CI/CD.
<type>: <subject>
[optional body]
[optional footer]
Subject line:
Body:
# Simple change
git commit -m "Fix contrast ratio calculation for transparent backgrounds"
# With body
git commit -m "Add keyboard navigation to command palette
Users can now navigate results with arrow keys and select with Enter.
Focus management returns to trigger element on close.
Closes #234"
A specification for machine-readable commit messages:
feat: add dark mode toggle
fix: prevent XSS in markdown preview
docs: update API response examples
refactor: extract validation logic to shared module
test: add unit tests for cron parser
chore: update dependencies
Tools can generate changelogs from conventional commits.
| Guideline | Reason |
|---|---|
| Atomic | One logical change per commit |
| Complete | Tests pass, lint passes |
| Explained | Future you will forget why |
| Reviewable | Small enough to understand in PR |
Bad commit history:
wip
fix
fix again
actually fix
cleanup
Good commit history:
Add base64 encoding logic with edge case handling
Add UI components for base64 tool
Wire up encoder to transform tool pattern
Add unit tests for base64 encode/decode
# Make sure you're up to date
git fetch origin
git rebase origin/main
# Run quality checks locally
npm run lint
npm test
npm run build
# Push your branch
git push -u origin feature/your-branch
## What
Brief description of the change.
## Why
Context: what problem does this solve?
## How
Implementation approach, if not obvious.
## Testing
How to verify the change works.
## Screenshots
If UI changed.
# Make requested changes
git add .
git commit -m "Address review: extract helper function"
# Or amend last commit if small fix
git add .
git commit --amend --no-edit
git push --force-with-lease
Use --force-with-lease instead of --force — it fails if someone else pushed to the branch.
git checkout main
git merge feature/new-tool
Creates a merge commit preserving branch history. Pros: complete history. Cons: cluttered log.
git checkout feature/new-tool
git rebase main
git checkout main
git merge feature/new-tool --ff-only
Replays your commits on top of main. Pros: linear history. Cons: rewrites commits (don't rebase shared branches).
Combines all branch commits into one on merge. Common on GitHub PRs.
Pros: clean main history. Cons: loses granular commits.
Pick one strategy and document it. Mixed approaches create confusing history.
| Strategy | Best for |
|---|---|
| Merge commits | Preserving detailed branch history |
| Rebase + fast-forward | Linear history purists |
| Squash merge | Clean main, detailed work in PR |
When Git can't auto-merge:
# During merge
git merge feature/branch
# CONFLICT: file.tsx
# Open conflicted files, look for markers
<<<<<<< HEAD
current code
=======
incoming code
>>>>>>> feature/branch
# Edit to resolve, then
git add file.tsx
git commit
# Unstage files
git reset HEAD file.tsx
# Discard working directory changes
git checkout -- file.tsx
# Amend last commit
git commit --amend
# Undo last commit, keep changes
git reset --soft HEAD~1
# Undo last commit, discard changes
git reset --hard HEAD~1
# Pretty log
git log --oneline --graph --all
# Search commits
git log --grep="fix contrast"
# Who changed this line
git blame file.tsx
# Find commit that introduced bug
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
# Save current changes
git stash
# List stashes
git stash list
# Apply most recent stash
git stash pop
# Apply specific stash
git stash apply stash@{2}
Copy a specific commit to current branch:
git cherry-pick abc1234
Useful for applying a fix to multiple branches.
Keep generated files, dependencies, and secrets out of the repo:
node_modules/
.next/
out/
dist/
.env
.env.local
*.log
.DS_Store
Generate a proper .gitignore for your stack with the Gitignore Generator.
Never commit .env files with secrets. Instead:
# .env.example (committed)
DATABASE_URL=
API_KEY=
NEXT_PUBLIC_SITE_URL=
# .env.local (gitignored, real values)
DATABASE_URL=postgres://...
Generate environment templates with the Env Template Generator.
If you accidentally commit secrets:
git filter-branch or BFG Repo-CleanerPrevention is easier than cleanup.
Git triggers your pipeline:
# .github/workflows/ci.yml
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run lint
- run: npm test
- run: npm run build
Configure on GitHub/GitLab:
Document and agree on:
When reviewing PRs or debugging, you often need to compare text. For quick file comparisons outside Git, use the Text Diff tool to paste and compare any two text blocks — config files, API responses, or generated output.
Git workflow is about communication as much as version control. Branch for isolation. Commit atomically with clear messages. Review code in PRs. Merge consistently. Keep main deployable. Use .gitignore and .env.example to keep the repo clean. When you inherit a project, git log tells you its story — make sure your commits add to that story clearly.
Master SemVer for libraries and apps — pre-releases, caret vs tilde ranges, breaking-change discipline, and a release workflow that keeps dependents sane.
A practical guide to agile frameworks — Scrum sprints, Kanban flow, XP, and Lean — with comparison tables, ceremonies, and honest advice on what actually works for software teams.
A practical guide to using AI in frontend development — code assistants, component generation, debugging, testing, and the workflows that make AI useful without losing code quality.
Find a developer tool