Why these Git commands confuse so many beginners
A lot of developers use these commands from memory:
git branch -M maingit checkout -b feature/inicialgit switch -c feature/inicialgit push -u origin feature/inicial
The problem?
Most people can type them.
Few people can clearly explain why they use them.
And that matters.
Because if you do not understand what these commands actually do, you will eventually mess up your branch flow, push to the wrong place, or confuse yourself when working across multiple repos.
Let’s fix that.
The real meaning of git branch -M main
This command:
git branch -M main
renames your current branch to main.
The important part is -M.
It is basically the forced version of branch rename:
-
-m→ rename branch -
-M→ rename branch and force it if needed
So when you run:
git branch -M main
You are not “creating GitHub main magic.”
You are simply saying:
Rename whatever branch I am currently on to
main.
What about master?
This command works the same way:
git branch -M master
The only difference is the target name.
Historically, many repositories used master.
Today, most modern repositories default to main.
Better option for brand new repos
If the repository is brand new, this is cleaner:
git init -b main
That way, you start with main immediately and avoid renaming later.
git checkout -b vs git switch -c: same result, different philosophy
These two commands are often used for the exact same outcome.
Classic Git style
git checkout -b feature/inicial
Modern Git style
git switch -c feature/inicial
Both commands:
- create a new branch
- move you to that branch immediately
So why do we have both?
Because checkout does too much
git checkout is one of those old Git commands that can do many unrelated things:
- switch branches
- restore files
- move around history
That flexibility is powerful, but also confusing.
git switch was introduced to make the intent much clearer.
When you write:
git switch -c feature/inicial
it is obvious that you are doing branch work.
That is why many teams now prefer switch for teaching and day-to-day use.
Which one should you use?
If you are working on a modern Git version, prefer:
git switch -c feature/inicial
It is clearer, easier to teach, and easier to read.
Why git push -u origin feature/inicial is more important than people think
Creating a local branch is only half the job.
Until you push it, GitHub does not know it exists.
That is where this command comes in:
git push -u origin feature/inicial
It does two things at once:
1) Pushes the branch to the remote
It sends your local feature/inicial branch to the remote called origin.
2) Sets upstream tracking
This is the part beginners usually skip over.
The -u means Git remembers the relationship between:
- your local branch
- the remote branch it tracks
So after this first push, you can usually just run:
git push
and later:
git pull
without typing the full branch name again.
That is why -u is such a useful habit.
The workflow most beginners actually need
If you want a simple, clean branch workflow, use this:
git init -b main
git add .
git commit -m "Initial commit"
git switch -c feature/inicial
git push -u origin feature/inicial
If you already initialized the repository and need to rename the current branch first:
git init
git branch -M main
git add .
git commit -m "Initial commit"
git switch -c feature/inicial
git push -u origin feature/inicial
That is enough for a huge number of personal projects and team workflows.
Can you do this with gh?
Partly, yes.
GitHub CLI is excellent for GitHub-related actions, but it does not replace core Git branch commands in the normal day-to-day flow.
What gh does well
It is great for creating the remote repository from the terminal:
gh repo create my-project --public --source=. --remote=origin --push
That command can:
- create the GitHub repo
- connect it as
origin - push your local code
What you should still do with Git
For regular local branch creation, Git is still the standard:
git switch -c feature/inicial
git push -u origin feature/inicial
Where gh becomes really useful again
Once the branch exists, gh is excellent for pull requests:
gh pr create --base main --head feature/inicial --title "Create initial feature branch" --body "This PR introduces the initial feature branch."
And if your team uses GitHub issues, there is a very useful workflow around issue-based branch creation.
The mistake many people make
They memorize the command.
They never learn the intent.
So they end up asking things like:
- “Why didn’t my branch appear on GitHub?”
- “Why does
git pushsay there is no upstream branch?” - “Why do I have
masterlocally andmainremotely?”
The answer is almost always the same:
They followed commands mechanically instead of understanding the branch lifecycle.
That lifecycle is simple:
create repo → define main branch → create feature branch → push and track upstream → open PR
Once you see that flow, the commands stop feeling random.
Final takeaway
If you only keep one mental model from this article, keep this one:
-
git branch -M main→ rename current branch tomain -
git checkout -b name→ create branch and switch to it -
git switch -c name→ same goal, cleaner modern syntax -
git push -u origin name→ publish the branch and set upstream tracking -
gh→ great for repo creation and PR workflows, not a full replacement for Git branch work
Git is easier when you stop memorizing commands and start understanding the sequence.
That is when branching becomes predictable instead of stressful.
Quick command summary
git init -b main
git switch -c feature/inicial
git push -u origin feature/inicial
If the repo already exists and you need to rename the current branch:
git branch -M main
If you want to create the GitHub repository from the terminal:
gh repo create my-project --public --source=. --remote=origin --push
What do you prefer in your daily workflow: git checkout -b or git switch -c?
If you are teaching Git to juniors, standardizing team workflows, or just trying to stop fighting branch confusion every week, start by simplifying the mental model—not just the commands.
Top comments (0)