Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
git push updates references—usually branches—in a remote repository and transfers the Git objects needed for those updates if the remote does not already have them. It does not simply upload every file or resend the entire project. Git first works out which remote and refs you mean; the remote can then check, accept, or reject the proposed updates.
1. Git chooses the remote and the refs to push
You can name a remote or URL explicitly, as in git push origin main. If you omit the repository, Git uses the current branch’s upstream when one is configured; otherwise, it defaults to origin. The Git 2.53.0 manual documents how Git chooses the refs: command-line refspecs and options take precedence, followed by remote.<name>.push configuration, then push.default. The default value of push.default is simple, which pushes a same-named branch. Git’s git-push manual
This is why the same short command can select different refs in different repositories: the current branch, its upstream, and the repository’s push configuration all matter.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →2. A refspec maps a local ref to a remote ref
A refspec tells Git which local reference is the source and which remote reference is the destination. Its general form is [+]<src>[:<dst>]. For example, main:other means “push local main to remote other.” With main alone, Git normally targets a remote branch with the same name.
#1 Best Overall
Options can broaden or change what is selected. --all selects branches, --tags selects tags, and --mirror mirrors refs. Deletion syntax and --follow-tags also change the set of refs involved. Those choices affect what Git proposes to update; they do not make every object in the local repository get sent.
3. Git transfers only the missing data needed for the update
Once it knows the destination refs, Git determines which objects are needed for the requested updates and sends the data the remote lacks. Git objects represent repository content and history; they are not merely a copy of the current files. If the remote already has required objects, Git does not need to send them again. The command’s stated purpose is to update remote refs and send necessary data not already present there. Git’s git-push manual
Rank #2
4. The remote can inspect and reject proposed updates
For a remote that uses Git’s receive service, incoming objects are initially placed in a quarantine directory rather than immediately becoming part of the main object store. An executable pre-receive hook runs once before refs are updated and can reject the push. An update hook runs separately for each ref and can reject an individual update. After successful updates, the service can run post-receive and then post-update. Hooks are optional server configuration, so they are not guaranteed steps on every push. Git’s git-receive-pack documentation
A rejection from a hook or server policy is different from Git refusing an update because it would move a branch backward. The rejection message is important: it can identify a rule, permission, or required workflow that a client-side history change will not fix.
5. Git checks whether the remote refs can be updated safely
For an ordinary branch update, Git requires a fast-forward: the remote branch’s current commit must be an ancestor of the commit being pushed. This protects work already on the remote from being silently displaced. If someone else has pushed commits that your local branch does not contain, Git will commonly reject your push as non-fast-forward.
If you intend to replace published history, --force-with-lease allows a non-fast-forward update only when the remote ref still has the value you expect. It is a safeguard, not a way to preserve remote work: if rewriting history is not intended, integrate the remote commits instead. Plain --force is not a routine fix, because it can overwrite commits added by someone else.
For multiple ref updates, --atomic requests an all-or-nothing update if the remote supports it. Without atomic support and a successful atomic request, a multi-ref push can have partial results: some refs may update while others do not. Server hooks or policies can also reject updates. Git’s git-push manual
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What different push choices change
| Choice | Refs selected | Allows non-fast-forward? | Can updates be partial? | Can the remote reject it? |
|---|---|---|---|---|
| Ordinary push | The refs selected by arguments and push configuration; a typical command pushes a branch. | No, not for an ordinary branch update. | Yes, when more than one ref is involved and the update is not atomic. | Yes. Hooks, permissions, or server policy can reject it. |
--force-with-lease |
The refs selected by the command and configuration. | Yes, if the remote ref still has the expected value. | Yes, unless a supported atomic update is requested. | Yes. The lease does not bypass server rules or hooks. |
--all |
All branches. | Not by itself; ordinary safety rules still apply. | Yes, unless a supported atomic update is requested. | Yes. |
--tags |
Tags. | Not by itself; ordinary safety rules still apply. | Yes, unless a supported atomic update is requested. | Yes. |
--atomic |
The refs selected by the rest of the command. | Not by itself; it changes transaction behavior, not fast-forward rules. | No, if the remote supports atomic updates and the request succeeds; otherwise the request fails rather than silently proceeding non-atomically. | Yes. A rejected update prevents the atomic set from being applied. |
For exact option behavior and examples, see the git-push manual. The Git project also lists common forms including git push, git push -u origin <name>, git push --force-with-lease, and git push --tags in its Git Cheat Sheet.
Best Value
Why a push is rejected—and what to do next
Non-fast-forward rejection
The remote branch has history your local branch does not include, or your proposed update would otherwise move the remote ref backward. Fetch and integrate the remote work, then retry a normal push. Use a history rewrite only when replacing the published history is intentional and you understand which remote state you are replacing.
Hook or policy rejection
Read the remote’s error output for the specific requirement. A hook may reject one ref or the whole push; a hosting service may also enforce permissions or repository rules. Fix the reported issue or ask the repository administrator about the policy rather than trying a force push.
Check without applying updates
git push --dry-run performs a dry run without actually sending updates. It can help you inspect what Git would attempt, but it does not guarantee that the remote will later accept the push: server-side checks may still determine the outcome of a real update. Git’s git-push manual
Recommended Free Tools
A successful push is not necessarily a deployment
Git’s push operation updates remote refs and sends repository data. Whether a hosting service subsequently runs a build, test suite, or deployment depends on that service’s configuration; those are not inherent steps in the Git command itself.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
