Ravindra BagaleCourses & study guides Track your progress

Guides

Git Branching and Pull Requests for Beginners

By , DevOps trainer LinkedIn Published: Last updated:

Read this guide in: English · मराठी · हिंदी

Why do we need branches and pull requests? Because there is a real problem when developers all write on main, and operations on the server side gets half-finished work. Two people push different features to the same live line; users feel the break; nobody reviewed. A branch is a side line for one job. A pull request (PR) is the review table before merge — so the server-side person only sees work the team agreed on.

Friends, first see the “both edited main” crash. Then PR feels obvious.

Quick answer

Hold this vertical picture:

  1. Developers — each needs space to finish a change.
  2. Operations — server-side employee who should deploy from stable main, not WIP.
  3. The problem — both push to main; mixed history; no review.
  4. Branch + PR — side line → review → merge when ready.
  5. Pocket loop: update main → branch → commit → push → open PR → merge.

Language: English · मराठी · हिंदी

Why do we need branching and PRs?

  1. Developers need to finish features without breaking what operations might deploy today.
  2. Operations (server-side) needs main releasable if the phone rings.
  3. Review catches mistakes before the server sees them.

You need Git basics and a GitHub repo you own.

What does operations have to do with PRs?

  1. Operations deploys and watches health on the server side.
  2. If main is a junk drawer, every deploy is a gamble.
  3. PRs protect main so both sides share one releasable line.

What is the problem? Suppose we are…

Suppose we are building Instagram (like updates)

Suppose one developer adds a profile badge on main while another rewrites the feed ranking on the same main. Both push. History mixes. Operations asks: which commit do I put on production?

Suppose we are working at Netflix and we are giving updates

Suppose two Netflix-style home-row fixes land unfinished on main the same afternoon. Millions of viewers can feel a bad merge. Review before merge is not optional at that scale.

Suppose you are working in Infosys on a client project

Suppose client operations only accepts changes that passed review. A PR is the paper trail: what changed, who approved, what was tested — before their server sees it.

Git: working tree, staging, commit history Edit files in the working tree, git add to stage, git commit to save a snapshot. Commits form history on the branch. Working tree edit files README.md add Staging git add index commit Repository (.git) git commit · snapshots c1 c2 c3 main → History answers: which build is live? (no mystery zip) status → add → commit Then git push shares the same history with the team / operations

Git path: edit in the working tree, git add to stage, git commit to save a snapshot on the branch history.

How branches and PRs answer that same fight

git checkout main
git pull
git checkout -b feature/profile-badge
# edit files …
git status
git add -A
git commit -m "Add profile badge field"
git push -u origin feature/profile-badge

Then on GitHub:

  1. Compare & pull request.
  2. Base: main. Compare: feature/profile-badge.
  3. Title + what changed / how you tested.
  4. Wait for CI if you have GitHub Actions.
  5. Address review comments with new commits on the same branch; merge; delete the branch.
  6. Locally: git checkout main && git pull && git branch -d feature/profile-badge.

Ravindra Bagale's Tip

Huge “refactored the world” PRs scare reviewers — same as dumping twenty unfinished features on Infosys client ops at once. One purpose per branch. Lakshat theva.

What you should see

  1. PR shows commits and a green/red diff.
  2. After merge, GitHub main includes your change.
  3. Locally after git pull on main, log shows the merge or squash.

Common errors — story pain then fix

Pain from the stories Likely cause Fix
PR has conflicts Main moved since you branched Update from main, fix, push
Pushed to main by mistake Wrong branch checked out Protect main; use branches
branch is behind Forgot git pull on main Update main before new branches
Empty PR No commits on the branch Commit on feature branch, push
Cannot delete branch Still checked out locally git checkout main first

Learn it properly

Samajla ka? Why branch/PR = stop half-finished work hitting the server-side person; Instagram / Netflix / Infosys “suppose”; side line → review → merge. One tiny PR tonight.

Frequently asked questions

What is a branch?

A branch is a movable line of commits so you can work without breaking main.

What is a pull request?

A PR asks to merge your branch into another branch after review.

Why not commit only on main?

Teams use branches so unfinished work stays isolated and reviews stay clear.

What is a merge conflict?

Two branches changed the same lines. Git asks you to pick the final text, then commit the fix.

Should I force-push?

Avoid force-push on shared branches. Prefer normal push after rebase only when your team agrees.

How long should a branch live?

Prefer short branches and small PRs — easier to review and safer to merge.