Why Your Git Branch Is Behind and How to Fix a Rejected Push

You finish your work, run git push, and Git refuses. The message says your branch is behind its remote counterpart, or that updates were rejected because the remote contains work you do not have locally. It feels like Git is blocking you for no reason.

In reality, Git is protecting your team. Someone, possibly you on another computer, pushed newer commits to the same branch, and Git will not let you overwrite them by accident. This guide explains exactly why your branch fell behind, how to catch up safely, and how to push again without losing anyone’s work.

Quick Answer

Git says your branch is behind when the remote branch has newer commits that your local branch does not have, so pushing would overwrite them. Fix it by running git pull to fetch and merge the remote changes into your branch, resolve any conflicts if they appear, and then run git push again. Using git pull --rebase is a clean alternative that replays your commits on top of the latest remote work.

What “Behind” Really Means

Your local branch and the branch on GitHub are two separate copies that need regular syncing. When a teammate pushes a commit, the remote copy moves forward. Your copy stays where it was, so Git now describes you as behind by however many commits you are missing.

You will see this in plain language when you run git status. It might say your branch is behind origin/main by 3 commits, and can be fast-forwarded. That is Git telling you the exact size of the gap and that catching up is easy, because you have no conflicting new commits of your own in the way.

The trickier phrase is behind and diverged, or that you and the remote have diverged. That means both sides added different commits since you last synced. Now there are two lines of history that must be woven back together with a merge or a rebase before any push is allowed.

Why Branches Fall Behind

• A teammate pushed first. The most common cause in team projects. They finished and pushed while you were still working.
• You worked on two computers. You pushed from your laptop yesterday and forgot to pull on your desktop today.
• Someone edited on GitHub directly. A quick fix through the web editor, or a merged pull request, moves the remote forward without touching your machine.
• You stayed on a long-lived branch. The longer you go without pulling, the further main moves ahead, and the bigger the catch-up becomes.
• A force push rewrote the remote. Rare, but if someone rewrote remote history, your branch can appear behind or diverged in confusing ways. Talk to your team before fixing this one alone.

How to Check Before You Fix

Do not fix blindly. Spend twenty seconds looking at the state of things first.

1. Run git fetch to download the latest information about the remote without changing any of your files.
2. Run git status and read the line about how far ahead or behind you are.
3. Run git log --oneline origin/main -5 to peek at the newest remote commits you are missing, and git log --oneline -5 to see yours.

This quick inspection tells you what is coming in before it lands in your code. If the incoming commits touch completely different files from yours, the catch-up will almost certainly be smooth. Our explainer on the real difference between git fetch and git pull goes deeper on why checking first with fetch is such a safe habit.

Fix Option 1: Pull With a Merge (The Beginner-Friendly Default)

1. Make sure your own work is committed. Run git status and commit anything important, because pull works most cleanly on a tidy tree.
2. Run git pull. Git fetches the remote commits and merges them into your branch automatically.
3. If Git reports a successful merge, possibly creating a merge commit, you are caught up.
4. If Git reports conflicts, resolve them file by file, stage the fixed files, and commit to complete the merge.
5. Run git push. With the remote work now inside your branch, the push will be accepted.

The merge approach preserves a completely honest history, including a visible record of when the two lines joined. For teams and beginners, that honesty is a feature. It is also the default behavior described in the official Git pull documentation.

Fix Option 2: Pull With Rebase (For a Straighter History)

Rebase takes a different approach. It lifts your local commits up, fast-forwards your branch to the latest remote state, then replays your commits one by one on top, as if you had started from the newest code all along.

1. Commit your work locally first, as with the merge option.
2. Run git pull --rebase.
3. If a conflict appears, Git pauses on the specific commit being replayed. Fix the file, stage it with git add, and run git rebase --continue. Repeat if needed.
4. When the rebase finishes, run git push as normal. No force is needed here, because you have not pushed these commits before in this form on an already-shared branch scenario the team agreed on; for branches only you use, this stays smooth.

Many developers prefer the tidy, straight line that rebase produces. The golden rule is to only rebase commits that have never been pushed and shared. Rebasing public history that teammates already have creates the very behind-and-diverged chaos you are trying to escape.

What You Should Never Do: Force Push

When a push is rejected, the tempting shortcut is git push --force. This tells Git to overwrite the remote branch with your version, deleting the remote commits you did not have. In other words, it solves your behind problem by erasing a teammate’s work.

Never force push a shared branch like main to fix a simple behind rejection. The correct fix always brings the remote work into your branch first. Force push has legitimate uses on your own private feature branches after a rebase, ideally in the safer --force-with-lease form, but it is never the answer to a normal rejected push on a team branch. If you believe the remote itself is genuinely wrong, stop and discuss it with your team before touching force options.

Common Mistakes to Avoid

• Force pushing to make the rejection go away. This can permanently delete teammates’ commits from the shared branch.
• Pulling only once a month. Small, frequent pulls create tiny catch-ups. Rare pulls create enormous, conflict-heavy ones.
• Ignoring the git status hint. The behind message includes exact commit counts and often the precise command to run. Read it fully instead of just seeing red text.
• Committing junk just to make pull work. If work is half-finished, stash it instead of committing broken code purely to unblock a pull.
• Rebasing commits that are already pushed and shared. This rewrites public history and leaves every teammate diverged. Merge is the safe choice for public branches.
• Assuming behind means something is broken. A behind branch is a normal, healthy state in any active project. It just means the project moved while you worked, which is a good sign.

Conclusion

A behind branch and a rejected push are Git doing its most important job: refusing to let anyone silently overwrite anyone else’s work. The fix is always to bring the remote commits into your branch first, with git pull for a merge or git pull --rebase for a straighter history, resolve any conflicts calmly, and then push again. Check with git fetch and git status before you act, pull little and often, and leave force push alone on shared branches. Follow that rhythm and this rejection will become a minor pause in your day instead of a panic.

Frequently Asked Questions

Will git pull overwrite my local commits?

No. A pull brings remote commits into your branch alongside yours. With a merge, both histories are preserved and joined. With a rebase, your local commits are replayed on top of the remote ones. Either way, your committed work is kept. What pull will not do is guess how to combine conflicting edits to the same lines, which is why it asks you to resolve those.

What does “behind by 2 commits, can be fast-forwarded” mean?

It means the remote has two commits you lack, and you have no new commits of your own that they lack. Catching up is a simple fast-forward: Git just slides your branch pointer forward to match the remote. A plain git pull handles this instantly with no merge commit and no conflicts.

Should I use merge or rebase to catch up?

For beginners and shared branches, merge with a plain git pull is the safer, clearer choice. Rebase gives a cleaner history and suits private branches and experienced users who follow the rule of never rebasing shared commits. The GitHub introduction to rebasing explains the trade-offs well if you want to adopt rebase later.

Why does this keep happening every single day?

Because your project is active, which is normal. Teammates push, pull requests merge, and web edits land while you work. Build a rhythm of running git pull at the start of each work session and before starting a new task, and the size of each catch-up will shrink to almost nothing.

My push was rejected but git status says I am not behind. What else could it be?

Other causes include protected branch rules on GitHub that require pull requests, missing permission to push to that repository, or a hook rejecting the commit content. Read the full rejection message carefully, since Git and GitHub state the specific reason, and it is not always the behind issue covered in this guide.