git push

You've made commits locally, and now you want to share them with your team or back them up to GitHub. git push uploads your commits to a remote repository, making them visible to everyone with access. It's how your work moves from your computer to the shared codebase, triggering pull request updates, CI pipelines, and team notifications.

The basic form is just git push, which pushes commits from your current branch to its configured upstream branch on the remote. If you're on feature-login and it's tracking origin/feature-login, your commits go there. The first time you push a new branch, you need to tell Git where to push with git push -u origin feature-login. The -u flag (short for --set-upstream) sets up tracking so future pushes on this branch just need git push without specifying the remote or branch name.

When you push, Git compares your local commits with what's on the remote. If your branch has commits that the remote doesn't, Git uploads them. If someone else has pushed commits you don't have, Git refuses to push and tells you to pull first. This prevents you from accidentally overwriting someone else's work. You'll see an error like "updates were rejected because the remote contains work that you do not have locally," which means you need to run git pull to merge their changes before pushing yours.

Force Pushing and Overwrites

Sometimes you need to override the remote branch completely, replacing its history with yours. This happens after rebasing or amending commits you've already pushed. Running git push --force does this, but it's dangerous—it can delete other people's commits if they've pushed work you don't have. A safer alternative is git push --force-with-lease, which only succeeds if the remote branch hasn't changed since you last fetched. If someone else pushed in the meantime, the push fails, protecting their work.

Force pushing is common in pull request workflows where you're the only person working on your feature branch. You push initial commits, get feedback, then rebase to incorporate review comments or clean up your commit history. After rebasing, a normal push fails because you've rewritten history, so you use --force-with-lease to update the PR. Just never force push to shared branches like main or develop—that can cause serious problems for your team.

Push Specific Branches and Tags

You can push specific branches with git push origin branch-name, which is useful when you have multiple local branches and only want to push one. To push all branches at once, use git push --all, though this is less common since it can accidentally push work-in-progress branches you meant to keep local.

Tags work differently from branches. By default, git push doesn't upload tags. You need git push --tags to push all tags, or git push origin v1.2.0 to push a specific tag. Teams use tags to mark releases, so pushing a version tag might trigger deployment pipelines or create GitHub releases.

Pull Request Integration

In pull request workflows, pushing is how you update your PR. When you push commits to a branch with an open PR, platforms like GitHub automatically update the PR to show your new commits. CI checks rerun, reviewers get notified, and your changes become visible immediately. This tight integration means you can iterate on feedback by making changes locally, committing, and pushing—the PR updates automatically.

Some teams configure branch protection rules that require status checks to pass before you can push to certain branches. If you try to push directly to main and tests are failing, the push gets rejected. This encourages using pull requests for code review rather than pushing directly to protected branches.

After your PR is merged, you typically delete the remote feature branch with git push origin --delete feature-branch. This keeps the remote repository clean and makes it clear which branches are still active. GitHub offers a button to delete branches automatically after merging PRs, which most teams enable.

Push Hooks and CI Triggers

When you push, remote Git hooks can run checks before accepting your commits. These might verify commit message format, run tests, or check for security issues. If a hook rejects your push, you'll see an error message explaining why. You'll need to fix the problem locally and push again.

Pushing also triggers continuous integration pipelines. The moment your commits reach the remote, CI systems like GitHub Actions start building your code, running tests, and performing other automated checks. When working on a PR, you see the results as status checks that appear on the pull request page within minutes.

Understanding push means understanding that it's the bridge between your local work and team collaboration. Until you push, your commits are invisible to everyone else. Once you push, they become part of the shared history, ready for review, testing, and integration. The key is knowing when to push (regularly to back up work and update PRs) and when to be careful (force pushing to shared branches or pushing untested code to protected branches).