Introduction

Git does not have a direct “push commit number 3 and 4 but not 5” command for the current branch tip. What you usually do instead is create a branch whose history ends at the commit you want to publish, or create a new branch and cherry-pick only the commits you want there.

Core Sections

Understand why push works this way

A Git push updates a branch reference on the remote. That means you are not really pushing “some commits” in isolation. You are pushing a branch tip and whatever commit history is needed to reach that tip.

So the practical question becomes: which branch tip should the remote branch point to?

If your local branch contains commits A, B, C, and D, and you want to publish only through B, you need a branch whose head points at B, not at D.

Option 1: create a branch at the commit you want to publish

If your branch history is linear and you want to publish only the earlier part of it, create another branch at the desired commit and push that branch.

git log --oneline
git branch publish-partial <commit-sha>
git push origin publish-partial

That branch contains history only up to the chosen commit. It is a safe approach because it does not rewrite your original local branch.

Option 2: cherry-pick selected commits onto a new branch

If the commits you want are not simply the earliest prefix of your local branch, create a fresh branch from the target base and cherry-pick the specific commits.

1git checkout master
2git pull origin master
3git checkout -b publish-selected
4
5git cherry-pick <commit-a>
6git cherry-pick <commit-c>
7
8git push origin publish-selected

This is often the cleanest answer when you want to publish only a subset of local work and the kept commits are not contiguous.

Option 3: rewrite local history before pushing

If you truly want your current branch itself to contain only the chosen commits, you can reorder, squash, or drop commits with interactive rebase before pushing.

git rebase -i HEAD~4

In the interactive editor, you can keep or drop commits, then push the cleaned-up branch.

This is useful before the branch has been shared. If the branch is already published and collaborators depend on it, rewriting history becomes riskier.

Use a new remote branch when in doubt

A good safety rule is: if you are unsure, do not force your current branch into shape immediately. Create a new branch and push that instead.

That gives you a reviewable, publishable branch without destroying local experimentation on the original branch.

It is usually better than trying to invent a one-line push command that partially publishes an in-progress branch while hiding later commits.

Common Pitfalls

• Thinking of git push as a commit-by-commit transfer instead of a branch-reference update.
• Trying to publish only selected commits from the current branch tip without creating a branch that actually ends at the desired commit.
• Using interactive rebase on a branch that is already shared without considering the impact of rewritten history on collaborators.
• Force-pushing when a new branch plus cherry-pick would have been safer and clearer.
• Forgetting to inspect the resulting history with git log --oneline --graph before pushing the branch you intend to publish.

Summary

• Git pushes branch tips, not arbitrary isolated commits.
• To push only some local commits, create a branch at the right commit or cherry-pick the chosen commits onto a new branch.
• Interactive rebase is useful when you want to rewrite the branch before publishing it.
• A new branch is the safest choice when you want partial publication without losing local work.
• Verify the branch history before pushing so the remote receives exactly the commits you intended.