Git Branch Commands Every Beginner Forgets: Delete Remote Branches, Rename Files, and Rebase Like a Pro

Key Takeaways

• Use git push origin --delete <branch> to remove remote branches from the command line
• Always use git mv instead of regular mv to preserve file version history
• Pull with --rebase to avoid messy merge commits on your master branch
• Configure your default branch name globally with git config --global init.defaultBranch main

Look, we've all been there. You learn git add, git commit, git push, and you think you've got this version control thing figured out. Then someone asks you to delete a remote branch and suddenly you're Googling frantically while pretending to type something important.

I've been collecting these beginner Git tips for a while now, and honestly? Even developers with years of experience mess these up. So let's fix that.

Deleting Remote Branches From the Command Line

Deleting a local branch is pretty straightforward. You've probably done it a hundred times:

The lowercase -d flag is the safe option. Git checks if the branch has been merged first. If you want to live dangerously and force delete regardless of merge status, you use the big D:

But here's where people get stuck. How do you delete that branch on GitHub or GitLab without clicking around in the web UI?

That's it. One command. No need to open your browser, navigate to branches, find the delete button. The kicker? Most people don't even know you can list remote branches from the terminal:

Renaming Files Without Destroying Your History

This one drives me crazy because I've seen senior developers make this mistake. Here's the scenario: your coworker John moves a script to a subdirectory and changes two lines of code. Now Git thinks the original file was deleted and a completely new file was created. All the version history? Gone. Poof.

The next time someone runs git blame, your name shows up as the author of the entire file. Even though you only touched two lines.

Git gets confused when you rename or move a file AND change its contents at the same time. It can't figure out that it's the same file. The solution is dead simple:

Instead of the regular mv command, use git mv. This tells Git explicitly that you're moving the file, not deleting one and creating another. Your commit history stays intact. Your coworkers won't hunt you down. Everyone's happy.

Why You Should Rebase When Pulling Master

Okay, this one's a bit more advanced but it'll save you from a really annoying situation.

When you push to a remote branch, your local branch needs to be ahead of the remote. That's called the fast-forward rule. On feature branches, you can force-push if things get messy. But on master? You should never force-push to master. Ever.

So how do you keep your local master ahead when you're pulling updates from the remote? You rebase:

If you don't use the --rebase flag and you have local changes, Git might create a merge commit on your local repo. And then you're stuck. You can't push to master because of the merge commit, and you definitely shouldn't force-push.

Setting Your Default Branch Name

Here's some context that trips up a lot of beginners. Until a couple years ago, every Git repository had a default branch called master. It was just how things worked.

Then there was a push to change this terminology, and GitHub was the first major platform to react. They switched the default to main. Git itself kept master as the default for a while, but added an option to change it.

So if you initialize a repo locally with git init, you might get master as your default branch while GitHub expects main. Confusing, right?

Here's how you set your preferred default branch name globally:

Now every new repo you create will use main instead of master. No more mismatched branch names between your local machine and GitHub.

Quick Reference: All Commands in One Place

Why These Commands Matter

I know what you're thinking. These seem like small things. And yeah, individually they are. But Git is one of those tools where small mistakes compound into massive headaches.

That merge commit you accidentally created on master? Now you're spending 30 minutes trying to figure out how to fix it without breaking anything. The file you renamed without git mv? Your team lead is asking why you rewrote an entire module when you only fixed a typo.

• Deleting remote branches keeps your repo clean and your branch list manageable
• Using git mv preserves blame history so the right person gets credit (or blame)
• Rebasing when pulling prevents merge commit nightmares
• Setting your default branch avoids confusion between local and remote repos

The Bottom Line

Git has a reputation for being confusing, and honestly, it deserves that reputation sometimes. The documentation is dense, the error messages are cryptic, and there are about fifteen ways to do everything.

But once you memorize these handful of commands, you'll handle 90% of the situations that trip up beginners. Print them out, stick them on a Post-it, save them somewhere. Your future self will thank you the next time you need to delete a remote branch at 4 PM on a Friday.

And hey, maybe don't be like John. Use git mv.

Frequently Asked Questions

What's the difference between git branch -d and git branch -D?

The lowercase -d is the safe option that checks if the branch is merged before deleting. The uppercase -D force deletes the branch regardless of merge status.

Can I recover a branch after deleting it from remote?

If someone still has the branch locally, they can push it back up. Otherwise, you might be able to recover it using git reflog if you're quick, but it's tricky.

Should I always use --rebase when pulling?

For your main/master branch, yes. For feature branches it depends on your team's workflow. Some teams prefer merge commits for clearer history of when features were integrated.

Source: DEV Community