Master Git branches without confusion: main, checkout, switch and push commands

Mistakes with Git branches often stem from using commands without understanding their purpose. The commands git branch -M main, git checkout -b, git switch -c, and git push -u origin are staples in many workflows, yet their underlying logic confuses newcomers. When commands are just typed by rote, errors like pushing to the wrong branch or losing track of changes become inevitable. Here’s how to move beyond memorization and use these commands with confidence.

What git branch -M main actually does under the hood

The command git branch -M main performs a single, specific action: it renames your current branch to `main`, even if the branch already exists. The -M flag combines two operations: it renames the branch and forces the change if needed, making it a powerful tool for correcting branch names or aligning with modern naming conventions.

The difference between -m and -M is subtle but important:

• -m attempts to rename the branch but fails if the target name already exists.
• -M forcefully renames the branch, overriding any existing branch with the same name.

For new repositories, setting the default branch during initialization is cleaner. Use:

git init -b main

This avoids the need for renaming entirely and ensures consistency from the start.

git checkout -b vs git switch -c: clarity over convenience

Both commands create a new branch and switch to it immediately, but their design philosophies differ significantly. The older git checkout -b achieves the goal, yet it’s part of a command with broader, often confusing functionality. checkout can switch branches, restore files, and even move through Git history, which makes it a Swiss Army knife that’s hard to teach.

The newer git switch -c was introduced to eliminate ambiguity. When you write:

git switch -c feature/login

The intent is crystal clear: you’re creating and switching to a new branch. For modern Git versions, prioritizing switch over checkout leads to cleaner, more readable workflows and reduces the cognitive load for teams.

Why -u in git push -u origin feature is a game-changer

Creating a local branch is only the first step; pushing it to a remote repository is what makes collaboration possible. The command git push -u origin feature does more than upload your branch:

• It pushes the branch to the remote (`origin`) so others can see it.
• It sets upstream tracking, linking your local branch to its remote counterpart.

Once upstream tracking is established, you can simplify future commands. Instead of:

git push origin feature/login

You can simply use:

git push

Similarly, git pull works without specifying the branch name. This behavior saves time and reduces errors, especially in active projects with multiple contributors.

A streamlined workflow for everyday use

For most projects—whether personal or team-based—this sequence covers the essentials:

1. Initialize a repository with main as the default branch:

git init -b main

1. Stage and commit initial changes:

git add .
git commit -m "Initial commit"

1. Create and switch to a feature branch:

git switch -c feature/login

1. Push the branch to the remote and set upstream tracking:

git push -u origin feature/login

If you’re working with an existing repository that still uses master, first rename the branch locally:

git branch -M main

Then proceed with the same workflow. This approach works for most small to medium-sized projects and avoids unnecessary complexity.

Where GitHub CLI shines—and where it falls short

The GitHub CLI (gh) excels at streamlining interactions with GitHub itself, particularly for repository creation and pull requests. For example, you can create a new repository, connect it to your local project, and push your code in one command:

gh repo create my-project --public --source=. --remote=origin --push

This command handles several steps at once, reducing setup time for new projects.

However, gh doesn’t replace core Git commands for day-to-day branch management. The syntax for creating branches and setting upstream tracking remains a Git responsibility:

git switch -c feature/update-ui
git push -u origin feature/update-ui

Where gh becomes particularly useful is after the branch exists. It simplifies pull request creation with clear, concise commands:

gh pr create --base main --head feature/update-ui --title "Update UI components" --body "Addresses button styles and accessibility issues."

For teams using GitHub Issues, integrating issue-based branch creation can further streamline workflows, making it easier to tie code changes directly to project tasks.

The root cause of most branch-related mistakes

The most common errors aren’t technical—they’re conceptual. Developers who treat commands as magic incantations often find themselves asking:

• Why didn’t my branch appear on GitHub after pushing?
• Why does git push report that no upstream branch is set?
• Why does my local branch show master while the remote shows main?

The answer usually boils down to a misunderstanding of the branch lifecycle. Git’s process is straightforward:

1. Initialize or clone a repository.
2. Define a default branch (main or master).
3. Create a feature or bugfix branch.
4. Push the branch and set upstream tracking.
5. Open a pull request for review.

Once you internalize this sequence, the commands stop feeling arbitrary. They become predictable tools that support your workflow instead of complicating it.

Closing thoughts: From memorization to mastery

The key to working effectively with Git branches isn’t knowing every flag or command by heart. It’s recognizing the lifecycle of a branch and aligning your actions with it.

Start with a clear intention: rename or initialize your default branch, create feature branches with intent, push with tracking in place, and use GitHub CLI to accelerate collaboration—not replace core Git operations. When commands become tools that serve your understanding, branching transitions from a source of stress to a reliable part of your development process.