Does git push all local commits after rebase?

Question

Let's assume two scenarios:

1. Working directly on the shared developer branch : Does a push after a rebase also transmit all commits that have been made before this rebase?

2. Working in a separate test-branch & merge into developer branch : Does a push of the developer branch after a rebase also transmit all commits that have been made before the rebase and the subsequent merge (test->developer) even if fast-forward mode?

Answer 1

Schleis' answer is correct, but to go into a little more depth, the "normal" (but optimized) process for a git push [ remote [ refspecs ... ]] goes something like this. We'll anthropomorphize your computer ¹ /git-push-process and call it "Bob", and also the remote in question, "Rem". The exchange goes like this:

BOB: "Hi, I have some branch refspecs for you, what do you have?"

REM: "I've got master , deploy , develop , and test ."

BOB: "OK, so I've got commit cabfa4e as the head of develop and fedcafe as the head of test and I'd like to send you what you need."

REM: "Well I'm already on fedcafe on test but I have badf00d on develop ..."

BOB: "Ah, well, I see badf00d here, I'll give you these new commits and tree/blob/tag objects [hands over long list of object data, packed up as a "thin" pack]."

REM: [pauses to digest the pack, run various hooks, verify that what Bob is giving him is OK and that it's OK to update develop ; if all goes well] "Thanks Bob!"

BOB: "OK bye, see ya later!"

(When this conversation is over, Bob knows that Rem-the-remote is now on cabfa4e on branch develop , so Bob updates remotes/rem/develop too.)

The point to all this is that Bob and Rem don't know, or even care, how they got into the state they were in when they exchanged data and Bob sent over new git-objects (commits, trees, blobs, and/or annotated tags). When they are done, Rem has whatever Bob sent, and if he "took" it (did not "reject" a reference update), Bob updates his record of what Rem has.

Just as important, Bob simply gives Rem the refspecs.

Let's say you decide to "rewind" ("remove") one or more commits, going from cabfa4e back to badf00d , and do a force-push. The conversation is a bit shorter—Rem already has all the objects—and there's a much greater chance Rem will say "nope, no can do, because I don't rewind commits". Bob will tell Rem that you asked for the push to be "forced" (Rem can still say "no" but the "built in default" is "not unless force", and you asked for "force").

Or, let's say you did not decide to rewind anything, but Rem had picked up new commits from Jan earlier, and you don't have them on your computer Bob. Rem now has develop at commit c0ffeee , which Bob does not have at all. Their earliest synchronization point is (still) at badf00d . Bob can propose to Rem: "Let's set develop to cabfa4e anyway, I'll give you everything from badf00d up through cabfa4e ." Rem will say "No, you're missing something (ie, that's not a fast-forward). I won't do that unless you say force." It's up to you to fetch-and-(merge/rebase), updating Bob to have c0ffeee (and maybe other commits as well).

It's all about the commit graphs. You (via Bob) propose to the remote (Rem) to change some parts of Rem's commit-graph by changing refs/heads/ labels to point to different commits; and you (Bob) provide the new parts of the graph, plus any other objects required; and then the remote (Rem) says "OK" or "not OK" according to Rem's rules (hooks). The default, built-in rule is: "Yes if the refs/heads/ label moves in a fast-forward fashion. Otherwise, yes if force, no if not force."

---

¹ "Don't anthropomorphize computers; they hate that."

Answer 2

git push attempts to update the remote repository to the same state as the local branch that you are pushing. So any commits that are in that branch will be added to the remote provided that the histories are compatible. You are not pushing a single commit but rather the state of the entire branch.