Feature branches and a protected main

CLI examples labeled Bash work in Git Bash on Windows 10 and Windows 11, or Bash on Linux, with Git installed. Bash variable assignments such as DEFAULT_BRANCH=main are shell syntax; use Git Bash for these examples rather than pasting them into PowerShell or Command Prompt.

Branching lets you change one feature without placing unfinished work on the shared integration branch. A feature branch is temporary: branch from an up-to-date main, develop and test, open a pull request, then delete the branch after merging. Prefer descriptive names such as feature/42-inventory or fix/57-save-crash so commits can be traced back to their issues.

Prepare a clean base

Before switching branches, inspect any uncommitted changes. Commit legitimate work to your current branch or otherwise save it safely. Do not discard changes simply to make a tutorial command succeed.

GitHub Desktop

1. Open Changes and verify what is still uncommitted.
2. Select Current Branch → main. If prompted about changes, review the choices rather than discarding them.
3. Click Fetch origin and then Pull origin if updates are available.
4. Select Current Branch → New Branch; use feature/42-inventory, based on main.
5. Click Create Branch. When you are ready to share, click Publish branch.

Git CLI

git status --short --branch
git switch main
git fetch origin
git pull --ff-only origin main
git switch -c feature/42-inventory
git branch --show-current
git push -u origin feature/42-inventory

Only switch after confirming your working tree is clean or your edits have been saved safely. The final push publishes the branch; you can defer it until you have something useful to share.

Protect the integration branch

A branch name alone does not prevent mistakes. On GitHub, use repository Rulesets or branch protection to require pull requests, successful checks and appropriate reviews. On GitLab, configure protected branches and merge-request approval rules according to your plan and organization policy. Limit direct pushes and force pushes to shared main. Permissions and settings vary by hosting plan.

For routine work, commit to the feature branch, push it and open a draft pull request if feedback is useful before completion. Keep changes small enough that a reviewer can understand the entire diff. Regularly fetch upstream changes, and resolve integration conflicts on your feature branch, not by experimenting on protected main.

Verify before merging

The merge-method guide explains the “Choose a branch to merge into” dialog, which branch changes, and how merge commits, squash and rebase differ.

Check the intended base branch, linked issue, meaningful commit history, tests and review comments. After the approved merge, record which commit was deployed. Delete the completed remote feature branch only after confirming nothing else depends on it. Never rewrite published team history casually.

Related: healthy workflow and GitHub’s branch guide.

Branch naming: main is an example. Use master or your repository’s actual default branch where applicable. See Git terminology.