Git Checkout vs Switch: Why Did We Need New Commands?
Every developer using Git is familiar with the git checkout
command. However, in August 2019, Git 2.23 introduced two new commands: git switch
and git restore
. Why did the Git team create new commands when checkout was working fine? And why do major IDEs like IntelliJ IDEA still stick to checkout?
The Original Sin of Checkout: Too Many Responsibilities
One Command, Too Many Functions
git checkout
has existed since the early days of Git. The problem is that this command does too many things.
# 1. Branch switching
git checkout main
# 2. Create and switch to a new branch
git checkout -b feature/new-feature
# 3. Restore file to previous state
git checkout -- README.md
# 4. Move to specific commit (danger: detached HEAD)
git checkout abc123def
# 5. Track remote branch
git checkout --track origin/feature-branch
One command handles two completely different tasks: branch switching and file restoration. While this might seem like a Swiss Army knife, it actually causes confusion for users.
Error-Prone Interface
There are particular problems that beginners frequently encounter.
Scenario 1: Unintended File Restoration
# Mistyped branch name...
git checkout maim # Typo while trying to type 'main'
# Git might attempt to restore a file called 'maim'
# If a file named maim exists, unexpected results occur
Scenario 2: Detached HEAD Hell
# Moving to a commit hash
git checkout abc123
# Now in detached HEAD state
# If you work and commit here... risk of losing work if you don't create a branch
The Birth of Switch: Clear Separation of Roles
The Revolution of Git 2.23
In August 2019, the Git development team made an important decision: to split the functionality of git checkout
into two commands.
git switch
: Dedicated to branch switchinggit restore
: Dedicated to file restoration
This decision followed the UNIX philosophy of "Do One Thing Well."
Switch vs Checkout: What's Different?
Branch Switching
# Old way
git checkout main
git checkout -b feature/login
# New way
git switch main
git switch -c feature/login # c for create
Preventing Detached HEAD
# Old: Easy to accidentally enter detached HEAD state
git checkout abc123def
# New: Must explicitly express intent
git switch --detach abc123def
# Switches to detached HEAD state with clear warning
More Intuitive Options
# Fetching remote branch
# Old
git checkout --track origin/feature
# New
git switch feature # Automatically tracks origin/feature
Restore: The New Way of File Restoration
git restore
is dedicated to file-related operations.
# Restore file in working directory
git restore README.md
# Remove from staging area (unstage)
git restore --staged README.md
# Restore file from specific commit
git restore --source=HEAD~2 README.md
# Restore entire directory
git restore .
Feature Comparison Table: At a Glance
Operation | git checkout | git switch | git restore |
---|---|---|---|
Branch switching | ✅ checkout main |
✅ switch main |
❌ |
Create new branch | ✅ checkout -b new |
✅ switch -c new |
❌ |
File restoration | ✅ checkout -- file |
❌ | ✅ restore file |
Detached HEAD | ⚠️ checkout hash |
✅ switch --detach hash |
❌ |
Unstage | ✅ checkout HEAD -- file |
❌ | ✅ restore --staged file |
- ✅ Feature supported
- ❌ Feature not supported
- ⚠️ Supported but requires caution (e.g., unintended detached HEAD state)
Reality: Why Do We Still Use Checkout?
IntelliJ IDEA's Choice
IntelliJ IDEA still uses checkout. To summarize JetBrains' official position: "We don't see a particular need to introduce these commands. Checkout still works perfectly and is compatible with all Git versions."
Main Reasons
- Backward compatibility: Supporting environments using older Git versions
- Stability: Maintaining proven workflows
- User habits: Preserving familiar interfaces
Other Tools' Responses
Visual Studio Code
- Still uses "Checkout" terminology in GUI
- Can use switch/restore in terminal
GitHub Desktop
- Uses user-friendly terminology ("Switch to branch")
- Executes appropriate Git commands internally
SourceTree
- Maintains traditional checkout interface
- Prioritizes stability and compatibility
Practical Choice: What Should You Use?
For New Projects
# Use switch for branch operations
git switch main
git switch -c feature/awesome
# Use restore for file operations
git restore src/app.js
git restore --staged .
For Existing Projects
- Check team's Git version (2.23 or higher)
- Review existing scripts and CI/CD pipelines
- Consider gradual migration
Recommendations
Recommended When
- Training new developers
- Starting new projects
- Git 2.23+ environment
Use Caution When
- Working on legacy systems
- Diverse Git version environments
- Many existing automation scripts
Git's Future: Will Checkout Disappear?
Official Position
The Git development team's position is clear: "Checkout is not deprecated and there are no plans to remove it in the near future."
Realistic Outlook
- Era of coexistence: checkout, switch, and restore will all continue to be supported
- Gradual transition: New users will learn switch/restore
- Tool evolution: IDEs and GUI tools will gradually adapt
The Harsh Reality: Limited Adoption of Switch
Let's be honest: it's been 5 years since Git 2.23 was released, but the adoption rate of switch
and restore
is disappointingly low.
The State of Education
- Most Git tutorials and courses still only teach
checkout
- Bootcamps, university courses, and online tutorials are all
checkout
-centric - The majority of Stack Overflow answers use
checkout
The Reality in the Field
- Even senior developers often don't know
switch
exists - Corporate documentation and guidelines are written based on
checkout
- CI/CD scripts and automation tools all use
checkout
Why Did This Happen?
- The Power of Inertia: Why change something that already works?
- Cognitive Load: It's easier to stick with what you know than learn new commands
- Network Effects: Everyone uses
checkout
, so I usecheckout
- Lack of Tool Support: Major IDEs and GUI tools remain
checkout
-centric
Conclusion: Toward Better Git
The introduction of git switch
and git restore
is part of the effort to make Git easier to use. By separating one complex command into two commands with clear purposes, Git is evolving into a more intuitive and less error-prone tool.
You don't need to change everything immediately. However, if you understand the clarity and safety provided by the new commands and choose to use them appropriately for your situation, you'll have a better Git experience.
Remember: Tools exist to help us. Whether it's checkout or switch, choose the method that works best for you and your team. What's important is that the choice should be an informed, conscious decision.