What does git push --force-with-lease do?

git push --force-with-lease force-pushes rewritten commits but first checks that the remote branch still matches what you last fetched. If a teammate has pushed new commits since your last fetch, the push is refused instead of silently overwriting their work — unlike plain git push --force .

How do I recover from a bad git rebase?

Run git reflog to list every state your local HEAD has visited, note the commit hash from before the rebase (for example HEAD@{5} ), then run git reset --hard HEAD@{n} to restore your branch to that point.

How do I abort a git rebase that's stuck in conflicts?

Run git rebase --abort to immediately cancel the in-progress rebase and restore your working tree to the exact state it was in before the rebase started.

Should I rebase a branch that other people have already pulled?

No — rebasing a shared branch rewrites commit IDs that teammates already have locally, forcing them to manually reconcile diverging histories. Finish with a regular merge instead, or coordinate explicitly and use --force-with-lease if you must rebase a branch others have pulled.

Git Rebase: Should You Rewrite Your Commit History?

Q: Is git rebase safer than git merge?

No — git rebase is not inherently safer than git merge, it is cleaner. Rebase rewrites commit history to produce a linear log, while merge preserves the true chronological history, including a merge commit. Both are safe when used on the right branches: rebase for solo or unshared branches, merge for shared branches.

Lately, I have implemented many features in my pet project and realised that none of the created branches were merged with the master code. And, I wanted to have a clean update. I was thinking that Git rebase is a perfect and safest solution since I am working on this project alone.

But then I stopped and asked myself: “Is it really safe? Should I even be doing this?”

If you’ve ever wondered the same thing, this post is for you. I’ll explain what Git rebase actually does, when it’s brilliant, and when it can cause absolute chaos. No panic, please. We’ll figure this out together.

TL;DR

Use rebase for a clean, linear history (solo work).
Use merge for shared branches (don’t rewrite history).
Always test and use --force-with-lease when pushing rebased code.
git reflog can save your day.

Note: In many newer Git repositories, the default branch is called main instead of master. The same logic applies — swap the name accordingly. I use master though :)

What Is Git Rebase?

Git rebase is a history-rewriting command that replays a branch’s commits on top of another branch’s latest tip, producing a linear commit log instead of a merge commit.

Here’s what actually happens: Git takes your feature branch commits, temporarily removes them, updates your branch to match the latest master, and then replays your commits one by one on top.

The result: a clean, linear history without messy merge commits cluttering your timeline.

Is Git Rebase Safer Than Git Merge?

🔒 Subscribe to keep reading.

How Git Rebase and Git Merge Differ Under the Hood

🔒 Subscribe to keep reading.

The Safe Git Rebase Workflow, Step by Step

🔒 Subscribe to keep reading.

When Is Git Rebase Safe vs. Risky?

🔒 Subscribe to keep reading.

Git Rebase Example: How Commit IDs Change

🔒 Subscribe to keep reading.

Git Rebase Recovery Commands: `git reflog` and `git rebase --abort`

🔒 Subscribe to keep reading.

Decision Guide: When to Use Git Rebase vs. Git Merge

🔒 Subscribe to keep reading.

Git Rebase Best Practices Summary

🔒 Subscribe to keep reading.

📚 Further reading

🔒 Subscribe to keep reading.

You've hit a Deep Dive tutorial.

I spend dozens of hours researching, coding, and breaking things to write these guides. This content is free, but reserved for my subscriber community. Drop your email below to unlock this guide (and all past/future deep dives):

Already a subscriber? Use the magic link from your last newsletter, or reset your password.

New subscribers get an inbox mail: Set a password to unlock articles. The form does not log you in — use the same email afterwards.

Should you use rebase?

📚 This post is part of the "Git Survival Guide" series

Git Rebase: Should You Rewrite Your Commit History?

What Is Git Rebase?

Is Git Rebase Safer Than Git Merge?

How Git Rebase and Git Merge Differ Under the Hood

The Safe Git Rebase Workflow, Step by Step

When Is Git Rebase Safe vs. Risky?

Git Rebase Example: How Commit IDs Change

Git Rebase Recovery Commands: `git reflog` and `git rebase --abort`

Decision Guide: When to Use Git Rebase vs. Git Merge

Git Rebase Best Practices Summary

📚 Further reading

References

Citation

Should you use rebase?

📚 This post is part of the "Git Survival Guide" series

Git Rebase: Should You Rewrite Your Commit History?

What Is Git Rebase?

Is Git Rebase Safer Than Git Merge?

How Git Rebase and Git Merge Differ Under the Hood

The Safe Git Rebase Workflow, Step by Step

When Is Git Rebase Safe vs. Risky?

Git Rebase Example: How Commit IDs Change

Git Rebase Recovery Commands: git reflog and git rebase --abort

Decision Guide: When to Use Git Rebase vs. Git Merge

Git Rebase Best Practices Summary

📚 Further reading

You're in

References

Citation

Git Rebase Recovery Commands: `git reflog` and `git rebase --abort`