Merge, squash, or rebase when completing a pull request?

Pick one convention per repository. Squash merging gives a clean one-commit-per-change history, merge commits preserve the full branch history, and rebasing keeps a linear history. Consistency matters more than which you choose.

How do feature flags help with short-lived branches?

They let you merge unfinished work to main safely, hidden behind a flag, so branches stay small while features are released only when ready.

Git Branching Strategies and the Pull Request Workflow

Introduction

A branching strategy is the team's agreement about where work happens and how it reaches production. A good one keeps the main branch releasable, makes reviews easy, and works smoothly with automated CI. This lesson compares the common strategies and walks through the everyday pull request workflow.

Prerequisites

Git installed and basic commands (add, commit, push)
A repository on GitHub, GitLab, or similar

Step-by-Step Guide

Step 1: Choose a strategy

Trunk-based development has everyone commit small changes to one main branch, or to very short-lived branches, and relies on feature flags and strong automated testing. GitHub flow uses a short-lived branch per change, reviewed through a pull request and merged to main, which is then deployed. Git Flow adds long-lived develop, release, and hotfix branches, which suits software with scheduled versioned releases but adds overhead. For most web and cloud services, trunk-based or GitHub flow works best.

Step 2: Work on a short-lived branch

Start from an up-to-date main, create a descriptively named branch, commit in small logical steps, and push it. Keep branches small and short-lived, ideally merged within a day or two, because long-lived branches cause painful merge conflicts.

git switch main
git pull
git switch -c feature/add-login-validation

# edit files, run tests...
git add .
git commit -m "Validate email format on the login form"
git push -u origin feature/add-login-validation

Step 3: Open and review a pull request

Open a pull request from your branch into main. Describe what changed and why, link the related issue, and keep it small enough that a reviewer can understand it in minutes. Reviewers check correctness, clarity, tests, and security. Your CI pipeline should run automatically on the pull request so problems show up before the merge.

Step 4: Protect the main branch

In your repository settings, use branch protection rules or rulesets so that main cannot be pushed to directly, changes need at least one approval, and required status checks, such as your CI build and tests, must pass first. This turns your agreements into enforced rules.

Step 5: Tag releases

Mark releases with annotated tags using semantic versioning: MAJOR.MINOR.PATCH, where MAJOR changes break compatibility, MINOR adds features compatibly, and PATCH fixes bugs. Tags give your pipeline and your team stable names to build and deploy.

git tag -a v1.2.0 -m "Release 1.2.0"
git push origin v1.2.0

FAQs

Merge, squash, or rebase when completing a pull request?: Pick one convention per repository. Squash merging gives a clean one-commit-per-change history, merge commits preserve the full branch history, and rebasing keeps a linear history. Consistency matters more than which you choose.
How do feature flags help with short-lived branches?: They let you merge unfinished work to main safely, hidden behind a flag, so branches stay small while features are released only when ready.

Summary

Prefer short-lived branches and small pull requests merged to a protected main. Let CI verify every change, tag releases with semantic versions, and pick the simplest strategy that fits your release process.