Push — what it is, how git push works, and when you need it

What is a Push in Git

Git push is a command that transfers commits from a local repository to a remote one. Unlike a commit, which saves changes only on the developer's local machine, a push publishes those changes for the entire team. Push is a mandatory step before creating a Pull Request and deployment.

Git's architecture assumes that each developer works in their own local repository. Commits are created locally and accumulate until the developer decides to push them. This provides freedom: you can make many local commits, experiment, and rewrite history without affecting colleagues.

# Push to origin remote, main branch
git push origin main

# Push current branch to remote with upstream
git push -u origin feature/new-dashboard

# Push all branches with matching names
git push --all origin

# Force push with lease (safe force push)
git push --force-with-lease

After a push, the remote repository updates refs (branch references) so they point to the new commits. Other developers can retrieve these changes via git pull or git fetch. This exchange of commits forms the basis of collaborative development.

How git push Works

The git push command compares local and remote branches and transfers only missing commits. Git does not resend all files — it transfers only the delta, making push fast even for large repositories. Git Protocol uses smart transfer, which minimizes the amount of data transmitted.

If the remote branch contains commits that are not present locally, the push will be rejected. This is a protective mechanism preventing loss of changes. In such a situation, the developer must first run git pull, merge the changes, and only then push again. An alternative is force push, which overwrites the remote branch, but it must be used with caution.

Understanding remote repositories is key to proper pushing. Typically, origin is the default remote repository name. The git remote -v command shows the list of remote repositories and their URLs. You can add multiple remotes (e.g., origin for the main repository and upstream for a fork).

When to Push Changes

The main rule: push after each logically completed stage of work. If a developer has finished a task or part of it — it’s time to push. However, pushing unfinished work that breaks the build is not recommended. Build not broken is the minimum requirement for pushing to any branch.

In team development, the following rhythm is adopted: in the morning — git pull to get colleagues’ changes, during the day — several commits and one or two pushes, in the evening — a final push of all completed tasks. The more often a developer pushes, the lower the risk of merge conflicts and the more transparent the work progress.

• After completing a task — commit and push the final solution to the feature branch
• Before leaving — push unfinished work to a feature branch (not to main!)
• Before creating a PR — make sure all commits are pushed and available for review
• After rebase — push with --force-with-lease to your feature branch

Safe Push Rules

Safe push is a set of rules that prevent data loss and conflicts in the team. The first and foremost rule: never push directly to the main or master branch if the project does not have direct deployment configured. In modern teams, main branch protection is configured at the GitHub branch protection level.

The second rule: synchronize with the remote branch before pushing. Run git pull --rebase to avoid merge commits when merging. This simplifies history and makes it linear. If a push is rejected — do not use bare force push, but first figure out which commits appeared on the remote branch.

The third rule: set up pre-push hooks that automatically run tests and linters before sending. If tests fail — the push is blocked. Such hooks are configured via Husky or Git hooks (pre-push file in .git/hooks).

The fourth rule: do not push large binary files. Git is not designed for storing binary artifacts — they bloat the repository and slow down operations. For large files, use Git LFS (Large File Storage). If a binary has already been pushed and is in the history, it must be removed via git filter-branch.

What to Do If Push Fails

The most common reason for a failed push is that the remote branch contains commits that are not present locally. This happens when another developer has pushed their changes to the same branch. Solution: run git pull, resolve any conflicts, and push again.

# Push rejected — fetch and rebase first
git fetch origin
git rebase origin/main
# Resolve conflicts, then:
git push --force-with-lease

# Or simply merge remote changes
git pull origin main
git push

The second reason — lack of write permissions to the branch. If the main branch is protected by branch protection rules, direct pushes are prohibited. Solution: push to a feature branch and create a Pull Request. Protection settings are usually administered via GitHub settings or GitLab protected branches.

The third reason — authentication issues. Outdated credentials, switching to SSH, or changed personal access token. Solution: check the remote URL (git remote -v) and update credentials. Since 2021, GitHub has deprecated password authentication for HTTPS — use a personal token or SSH key.