Git Notes
The git push command uploads your local commits to a remote repository, making your work available to other team members. It is the counterpart to git pull...
The git push command uploads your local commits to a remote repository, making your work available to other team members. It is the counterpart to git pull — while pull brings changes down from the remote, push sends your changes up. Understanding how push works, its safety mechanisms, and common pitfalls will save you from many collaboration headaches.
How Push Works
When you push, Git sends the commits from your local branch to the corresponding branch on the remote repository. Git only transfers commits that the remote does not already have — it is incremental, not a full upload.
git push origin mainThis command means: "Send my local main branch commits to the origin remote's main branch."
For a push to succeed, the remote branch must be a direct ancestor of your local branch (your branch must be ahead, not diverged). If the remote has commits you do not have locally, Git rejects the push and asks you to pull first.
Basic Push Operations
Push to the tracked upstream branch:
git pushPush a specific branch:
git push origin feature/authenticationPush and set upstream tracking (first push of a new branch):
git push -u origin feature/authenticationThe -u flag (or --set-upstream) links your local branch to the remote branch so future git push and git pull commands work without specifying the remote and branch name.
Push all local branches:
git push --all originPush tags:
git push origin v1.0.0 # Push a specific tag
git push origin --tags # Push all tagsPush Rejection and How to Handle It
The most common push error occurs when someone else has pushed changes you do not have:
The solution is to integrate remote changes first:
git pull origin main # Fetch + merge remote changes
git push origin main # Now push succeeds
# Or with rebase for cleaner history:
git pull --rebase origin main
git push origin mainForce Push: Power and Danger
Sometimes you need to overwrite the remote branch — after a rebase, for instance:
git push --force origin feature/my-branchThis is dangerous because it overwrites the remote history. If someone else has based work on those commits, their branches become incompatible.
The safer alternative is --force-with-lease:
git push --force-with-lease origin feature/my-branchThis force-pushes only if no one else has pushed to that branch since you last fetched. If someone else has pushed new commits, the push fails — protecting you from accidentally overwriting their work.
Push Workflow for Feature Branches
The typical workflow when developing a feature:
# Create and switch to feature branch
git checkout -b feature/shopping-cart
# Make changes and commit
git add .
git commit -m "Add cart data model"
# More commits...
git commit -am "Add cart UI components"
git commit -am "Add cart API integration"
# Push the branch for the first time
git push -u origin feature/shopping-cart
# After more local commits, push updates
git push
# After rebasing on main (rewrite history), force push safely
git rebase main
git push --force-with-leasePush Configuration
Configure default push behavior:
# Push only the current branch (default in modern Git)
git config --global push.default current
# Automatically set upstream when pushing a new branch
git config --global push.autoSetupRemote trueWith push.autoSetupRemote, you never need -u — Git automatically creates the tracking relationship on first push.
Common Mistakes
Pushing to the wrong branch:
# Accidentally pushed feature work to main
git push origin main # Oops!
# Fix: Reset remote main to the correct commit
git push --force-with-lease origin correct-sha:mainPushing sensitive data:
If you accidentally commit secrets or credentials:
# Remove the file from history (requires force push)
git filter-branch --force --tree-filter 'rm -f secrets.env' HEAD
git push --force-with-lease origin mainBetter yet, use .gitignore and environment variables from the start.
Pushing broken code to a shared branch:
Always run tests before pushing:
npm test && git push origin mainPush in Team Workflows
Different teams have different push policies:
Direct push to main — Small teams where everyone pushes directly.
Feature branch + PR — Push to feature branches, merge to main via pull request after code review.
Protected branches — Main branch blocks direct push; only merged PRs from approved reviews can update it.
# Standard team workflow
git push origin feature/my-work
# Then create a Pull Request on GitHub
# After approval and CI passes, merge via GitHub UIPre-Push Hooks
Git hooks can validate your code before pushing:
This prevents pushing code that fails tests, catching problems before they reach the remote.
Key Takeaways
Git push is how your work becomes visible to the world. Always ensure your branch is up-to-date before pushing, use -u on first push to set up tracking, and prefer --force-with-lease over --force when you must overwrite history. In team environments, push to feature branches and use pull requests rather than pushing directly to shared branches. Good push hygiene — small, tested, well-described commits — makes collaboration smooth for everyone.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Git Push.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.
Search Terms
git-github, git & github, git, github, collaboration, push, git push
Related Git & GitHub Topics