Orphan Branches
Orphan branch ki pehli commit root hoti hai. Inhe merge mat karna — independent rakho, yeh alag duniya hain.
Orphan branch = parallel universe. When you run git checkout --orphan branch-name, Git creates a branch with no parent commit. It does not branch off from any existing commit — it starts completely fresh.
A regular branch points to the current commit as its starting point. An orphan branch points to nothing. Its first commit has no parent — it is a new root commit.
This means your repository now has two independent histories. The main branch has its timeline, the orphan branch has its own separate timeline. They share zero commits.
Common uses for orphan branches:
- gh-pages — GitHub Pages static site hosting
- Docker context — isolated Dockerfile and build files
- Changelog — standalone changelog without bloating main
- Documentation — separate docs site with its own history
The key insight: orphan branches share NO history with main. They are completely independent timelines in the same repository.
# Create an orphan branch for GitHub Pages
git checkout --orphan gh-pages
# Everything from main is staged! Clean it first.
git rm -rf .
# Now you have an empty, clean branch
git status
# nothing to commit
# Add your pages files
echo "<h1>Hello Pages</h1>" > index.html
git add .
git commit -m "init gh-pages"
# These two branches share NO history
git log --oneline main # history of main
git log --oneline gh-pages # gh-pages history (totally different root)After creating an orphan branch, ALL files from the current branch are staged. This catches every beginner off guard.
Why? Because git checkout --orphan switches to the new branch but keeps your working directory and index exactly as they were. Everything that was tracked on the previous branch is now staged and ready to commit on the orphan branch.
If you commit without cleaning, you will publish your entire application — including node_modules, .env files, and secrets — onto the orphan branch. This is the #1 orphan branch mistake.
The fix is simple: git rm -rf . — this removes all tracked files from the index, leaving your working directory with the files but Git no longer tracks them.
Then selectively add only the files you want on the orphan branch.
# Create orphan branch
git checkout --orphan gh-pages
# DANGER: Everything is staged!
git status
# Changes to be committed:
# new file: app.js
# new file: package.json
# ... all your project files!
# CLEAN IT!
git rm -rf .
# Now clean
git status
# nothing to commit
# Add only pages files
echo "<h1>My Site</h1>" > index.html
git add index.html
git commit -m "init gh-pages"git rm -rf . immediately after creating an orphan branch. Make it a reflex: orphan = clean first. If you forget, you risk committing your entire project — including sensitive files — to a branch that might be publicly accessible via GitHub Pages.The gh-pages branch is the traditional approach for hosting static websites on GitHub Pages. Using an orphan branch keeps website assets completely separate from application code.
When you push a gh-pages branch to GitHub, GitHub automatically serves the static files as a website at username.github.io/repo-name.
The orphan approach means your website history and application history never mix. Your main branch stays clean with application commits, while gh-pages has only website-related commits.
Modern GitHub Pages also supports deploying from main/docs folder or GitHub Actions. But the orphan gh-pages branch is still the cleanest approach for standalone sites.
# Full gh-pages workflow
git checkout --orphan gh-pages
git rm -rf .
# Create site
cat > index.html << 'EOF'
<!DOCTYPE html>
<html>
<head><title>My Project</title></head>
<body><h1>Hello from GitHub Pages!</h1></body>
</html>
EOF
git add index.html
git commit -m "init gh-pages"
git push -u origin gh-pages
# On GitHub: Settings -> Pages -> Source: gh-pages branch
# Your site is live at: username.github.io/repo-nameOrphan branches are not just for GitHub Pages. Any content that should not share history with your main codebase is a candidate.
Docker build context: isolate your Dockerfile and docker-compose.yml from application code. The Docker context has its own history — no need to see app commits when reviewing Docker changes.
Changelog: maintain a standalone CHANGELOG.md without bloating main history. Each release gets a clean changelog entry without merge noise.
Configuration: separate branch for environment-specific configs. Production, staging, development — each with its own independent history.
Experiments: start fresh without any history baggage. Try something wild without worrying about polluting your main timeline.
# Docker context branch
git checkout --orphan docker
git rm -rf .
echo "FROM node:18" > Dockerfile
git add Dockerfile
git commit -m "init docker context"
# Changelog branch
git checkout --orphan changelog
git rm -rf .
echo "# Changelog" > CHANGELOG.md
git add CHANGELOG.md
git commit -m "init changelog"Orphan branches have no common ancestor with main. This means merging them creates bizarre results and pollutes both histories.
When you merge an orphan branch into main, Git creates a merge commit that joins two completely unrelated histories. Your git log becomes confusing — two separate timelines suddenly merged into one.
If you need content from an orphan branch on main, there are better approaches:
- Copy files manually:
git show gh-pages:index.html > docs/index.html - Cherry-pick specific commits:
git cherry-pick <hash> - Keep them separate forever: this is the whole point of orphan branches
Orphan branches are designed to be independent. Merging them defeats the entire purpose. Keep them separate, and if you need to share content, copy it manually.
# BAD: Merging orphan branch into main
git checkout main
git merge gh-pages
# Merge made by the 'ort' strategy.
# Creates confusing history with two root commits!
# GOOD: Keep them separate
# If you need a file from gh-pages on main:
git checkout main
git show gh-pages:index.html > docs/index.html
git add docs/index.html
git commit -m "docs: add site to docs folder"
# Or cherry-pick specific commits
git cherry-pick <hash-from-gh-pages>Lo kar liya — Key Points:
- ✅ git checkout --orphan name creates a branch with no parent commit — a parallel history
- ✅ After creating an orphan branch, ALL current files are staged — you MUST run git rm -rf . to clean the index
- ✅ Common use: gh-pages branch for GitHub Pages, Docker contexts, and changelogs
- ✅ Orphan branches share NO history with main — they have independent root commits
- ✅ NEVER merge orphan branches into main — they have no common ancestor, creating confusing history
- ✅ To transfer content, use git show branch:file or git cherry-pick specific commits
Want to track your progress?
Log in to save your place and pick up where you left off.
Progress track karna chahte ho?
Login karo apni progress save karne ke liye aur jahan chhoda tha wahan se shuru karo.
Login