Git Branching, Merging, and Pull Requests Explained for Beginners

Once you understand what Git is and how to make commits, the next thing you must learn is how to actually collaborate — how to work on a feature without blocking everyone else, how to combine your work back, and how to get your code reviewed before it ships. The three concepts that make this possible are branches, merging, and pull requests, and together they describe the daily workflow of every software team in 2026.

This guide walks through each one with simple analogies, real commands, and the small set of habits that separate a confused beginner from a teammate people enjoy working with. By the end you will be able to open a PR with confidence and know exactly what happens when you click "Merge."

What a Branch Actually Is

A branch is a movable pointer to a commit. That is it. There is no copy of your files on disk — Git just remembers "this branch points at commit X." When you create a new branch you are saying "from this point, I want to start a separate line of work that I can experiment on without affecting anyone else."

Mental model: think of main as the trunk of a tree and feature branches as twigs growing off it. You sketch your idea on a twig; if you like it, you graft it back into the trunk. If you hate it, you snip the twig and nothing on the trunk is affected.

bash

$ git switch -c feature/login   # create + switch to a new branch
$ git branch                    # list local branches
$ git log --oneline --graph --all   # see the tree

Branches are absurdly cheap in Git — you can create, switch between, and delete dozens a day. Use one for every non-trivial change. Never commit directly to main.

The Standard Daily Workflow

Almost every team in 2026 follows the same pattern, sometimes called GitHub Flow:

1. Pull the latest main: git switch main && git pull.
2. Create a feature branch: git switch -c feature/add-search.
3. Make commits on that branch as you work: edit → git add → git commit -m "...".
4. Push the branch: git push -u origin feature/add-search.
5. Open a Pull Request on GitHub against main.
6. Get review, address feedback, push more commits.
7. Once approved + CI passes, click Merge.
8. Delete the branch (GitHub offers a button right there).

This loop happens hundreds of times a day in healthy teams. Each PR is small, focused, and reviewed before it touches main.

Merging: How Branches Come Back Together

When your branch is ready, Git needs to combine your commits into main. There are three common strategies, and most repos pick one and stick with it:

• Merge commit — creates a new commit that ties both histories together. Preserves the full branch structure. Default in older repos.
• Squash merge — collapses all your branch's commits into a single commit on main. Clean, linear history. Default for most modern teams in 2026.
• Rebase merge — replays your commits on top of main, one by one, creating a perfectly linear history with no merge commit. Strict shops love it.

For 90% of beginners, squash merging is the easiest. Your messy "fix typo" and "wip" commits on the branch become one tidy commit on main, with the PR title as its message.

Pull Requests Are Just Conversations

A pull request (PR) — called a merge request on GitLab — is a GitHub feature, not a Git feature. It is a structured conversation around proposed changes:

"Here are the commits on my branch. I would like to merge them into main. Please review."

A PR shows the diff, lets reviewers leave inline comments, runs your CI pipeline (see What is CI/CD?), and only allows merging once any required checks and approvals are satisfied. It is the gate between "I think this works" and "this is in production."

A good PR has:

• A clear title describing the change.
• A short description explaining why (what problem does this solve?).
• Screenshots/GIFs for any UI change.
• Small scope — under 400 lines of diff is the sweet spot. Massive PRs do not get reviewed properly.
• Passing CI before you ask anyone to look at it.

Handling Merge Conflicts

A conflict happens when Git cannot automatically combine two changes — both branches edited the same lines of the same file in different ways. Git pauses and asks you to decide.

text

<<<<<<< HEAD
button: 'Submit'
=======
button: 'Send'
>>>>>>> feature/rename-button

The fix is mechanical: open the file, delete the markers (<<<<<<<, =======, >>>>>>>), keep the version you want (or some combination), save, and:

bash

$ git add <file>
$ git commit          # finishes the merge

Conflicts feel scary the first time and routine after the third. They are not a sign you did anything wrong — just that two changes overlapped.

Keeping Your Branch Up to Date

Long-running branches drift behind main. Two ways to catch up:

bash

$ git switch feature/x
$ git fetch origin
$ git rebase origin/main      # OR
$ git merge   origin/main

rebase rewrites your branch's commits to sit on top of the latest main — clean, linear history. merge brings main's changes into your branch with a merge commit — safer but messier. Both work; pick one and be consistent.

A rule: never rebase a branch other people are using. Rewriting shared history breaks teammates' clones. Rebase your own feature branches; merge for shared ones.

Common Mistakes Beginners Make

• Working on main. Branch protection should make this impossible, but the habit matters. git switch -c feature/x first, every time.
• Massive PRs. A 3,000-line PR will not get a real review — reviewers will skim and approve. Split into smaller, sequential PRs.
• Force-pushing shared branches. git push --force on a teammate's branch is a great way to lose their commits. Use --force-with-lease and only on your own branches.
• Vague commit messages. "fix" tells your future self nothing. Write what changed and why: "Fix login redirect when session expires."
• Not pulling before starting work. Always git pull on main before branching. Otherwise your "new" feature branch is born stale.

Quick Reference

• New branch: git switch -c feature/x. Switch existing: git switch feature/x.
• List branches: git branch -a (all, including remote).
• Push new branch: git push -u origin feature/x.
• Update from main: git fetch && git rebase origin/main.
• Open a PR (CLI): gh pr create --fill.
• Merge a PR (CLI): gh pr merge --squash --delete-branch.
• See PR list: gh pr list. Check out someone else's PR: gh pr checkout 123.
• Abort a merge: git merge --abort. Abort a rebase: git rebase --abort.
• Delete local branch: git branch -d feature/x. Delete remote: git push origin --delete feature/x.