Best for: Small teams (2-8 developers), continuous deployment, teams that deploy multiple times per day.

The idea is simple. Everyone commits to a single branch (main/trunk), either directly or through very short-lived feature branches that last hours, not days.

Rules:

• •Feature branches live for less than 24 hours
• •Every commit to main must pass CI
• •Use feature flags instead of long-lived branches for incomplete features
• •Keep changes small -- one logical change per commit

Advantages:

• •Almost zero merge conflicts
• •Always-deployable main branch
• •Forces small, reviewable changes
• •No "integration hell" when merging long-lived branches

Best for: Medium teams (5-20 developers), projects that deploy frequently but want code review on every change.

GitHub Flow adds one layer on top of trunk-based development: every change goes through a pull request.

Rules:

• •Main is always deployable
• •Create a feature branch from main for every change
• •Open a pull request when the work is ready for review
• •After review and CI passes, merge to main
• •Deploy from main

This is what most modern teams use. It is simple enough that everyone follows it, but structured enough that nothing sneaks into main without review.

Best for: Large teams, projects with scheduled releases, mobile apps that go through app store review.

GitFlow uses multiple long-lived branches: main, develop, feature branches, release branches, and hotfix branches. It provides structure for teams that cannot deploy continuously.

Rules:

• •Main always contains production-ready code
• •Develop is the integration branch for features
• •Feature branches are created from develop and merged back into develop
• •Release branches are created from develop when preparing for a release
• •Hotfix branches are created from main for emergency fixes

The downside: GitFlow is complex. Most teams that adopt it end up simplifying it over time because the overhead of managing all those branches outweighs the benefits.

Keep it under 72 characters. Start with a verb. Be specific.

Bad: "Updates", "Fix bug", "Changes to auth"

Good: "Add email verification to signup flow", "Fix crash when user submits empty form", "Replace bcrypt with argon2 for password hashing"

Every PR description should answer three questions:

1. 1What does this change do?
2. 2Why is this change needed?
3. 3How can the reviewer test it?

A simple template:

> ## What

> Added rate limiting to the /api/login endpoint.

>

> ## Why

> We were getting hit with brute force attempts. This limits each IP to 5 attempts per minute.

>

> ## How to Test

> 1. Start the server locally

> 2. Hit /api/login more than 5 times in a minute

> 3. Verify you get a 429 response on the 6th attempt

The most important rule of pull requests: keep them small. Research consistently shows that review quality drops dramatically as PR size increases.

• •Under 200 lines: reviewed carefully, merged quickly
• •200-500 lines: reviewed with decreasing attention
• •Over 500 lines: skimmed at best, rubber-stamped at worst

If your feature requires more than 500 lines, break it into multiple PRs. Ship the data model first, then the API, then the UI.

• •Review within 24 hours. Stale PRs kill momentum. If you cannot review today, say so and suggest another reviewer.
• •Focus on what matters. Logic errors, security issues, and architectural problems are worth discussing. Nitpicking variable names and formatting is not (use a linter for that).
• •Ask questions instead of making demands. "What happens if this API call times out?" is better than "Add error handling here."
• •Approve with comments. If you have minor suggestions that do not block the PR, approve it and note them as optional. Do not block PRs over style preferences.

• •Self-review before requesting review. Read your own diff. You will catch half the issues yourself.
• •Respond to every comment. Even if the response is "Done" or "Good point, fixed." Unanswered comments create ambiguity.
• •Do not take feedback personally. Code review is about the code, not about you. A suggestion to restructure something is not a judgment of your abilities.

Creates a merge commit that preserves the entire branch history. Your git log shows exactly when branches were created and merged.

Best for: Teams that want a detailed, accurate history of how code was developed.

Combines all commits in the branch into a single commit on main. The individual commits in the feature branch disappear from main's history.

Best for: Teams that want a clean, linear main branch history. Every commit on main represents one complete feature or fix.

Replays the commits from the feature branch on top of main, creating a linear history without a merge commit. Each commit is preserved individually.

Best for: Teams that want a linear history but also want to preserve individual commits within a feature.

• •Squash and merge is the most popular choice for most teams. It keeps main clean and makes reverts easy -- one commit equals one feature.
• •Merge commits work well for teams that want to preserve detailed development history.
• •Rebase and merge is for teams that are disciplined about making each commit meaningful and self-contained.

Pick one strategy and use it consistently across the team.

• •Pull from main frequently. The longer your branch lives, the more likely conflicts become.
• •Communicate with your team. If two people are editing the same file, coordinate.
• •Keep PRs small. Smaller changes mean smaller conflict surfaces.

When you hit a conflict:

> git fetch origin

> git rebase origin/main

Git will pause at each conflict. Open the conflicting file, and you will see:

> <<<<<<< HEAD

> your changes

> =======

> their changes

> >>>>>>> origin/main

Resolve it by keeping the correct code, removing the conflict markers, then:

> git add the-file.ts

> git rebase --continue

If the conflict is too complex, you can always abort:

> git rebase --abort

• •VS Code has excellent built-in merge conflict resolution. Click "Accept Current Change", "Accept Incoming Change", or "Accept Both Changes."
• •git rerere (reuse recorded resolution) remembers how you resolved a conflict and automatically applies the same resolution if it comes up again. Enable it with: git config --global rerere.enabled true