What exactly happens in a git push? Why isn't a git push considered just like a git merge?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP



What exactly happens in a git push? Why isn't a git push considered just like a git merge?



So as mentioned here a git pull is just fetching the latest and then merging them.
Isn't that the same for a git push? ie from the remote...you fetch the local and merge it into the branch?


git pull


git push



Or is that you're not merging anything, rather you're totally re-writing history of commits...ignoring whatever was there and just replacing commit lists with a newer one?



(I'm fully aware of when the use git push ie I use when I'm done with a feature in my local. I push into my origin. My question is more about what happens under the hood)


git push





Pushing doesn't rewrite the history on the remote unless your local branch rewrites history, and even then, I think you need to use the --force flag.
– Abizern
Aug 10 at 14:35


--force





Push and pull are semantically opposites, but not at all symetrical operations in git. You don't rewrite anything when you pull or push (--force is another subject), you add to the existing tree. And there's no merging process happening on remote. Merges are supposed to be dealt with locally, then pushed on top of the remote tree.
– RomainVALERI
Aug 10 at 14:42






You aren't rewriting history. the original 1->2->3 is still there, you've just added 4 on top of it. This isn't rewriting history, it's adding to it.
– Abizern
Aug 10 at 14:44





Totally re-writing the history of commits? Replacing commit lists? That would defeat the purpose entirely. You have to tell it to screw with commit history, and in general, you don't need to. The only common time you screw with history is when you're squashing stuff before sending it up, and even then, things can go very wrong.
– Dave Newton
Aug 10 at 14:45






git push is a bit like a fast-forward merge. If it's a true merge, it would be rejected and fail.
– ElpieKay
Aug 10 at 14:54


git push




1 Answer
1



git pull pulls the latest commits from the remote to your local client.


git pull



git push pushes your latest local commits from your local client to the remote.


git push



When you push, if your local repository does not have all commits from the remote, the push is rejected, not merged into the remote branch as you seem to think. In this case you must first pull the remote's latest changes and either merge or rebase your local changes. Now your local repository is ahead of the remote and you can proceed to push.


push


push


pull


merge


rebase


push



In the special case where local and remote histories match, you could look at the push as symmetrically opposite to the pull, i.e. the remote "pulls" the changes from the local, and you're right that in this case. The merge strategy would be equivalent to pulling new changes from remote (specifically the merge strategy is fast-forward; explained about halfway down this page). However a remote repo doesn't work exactly like a local repo, there's no way to login to the remote and pull; rather the command is being run on the local so we must use the correct verb, push.


push


pull


pull


fast-forward


pull


push





can you see the comments above and possibly edit your question accordingly. I'm still missing something in the foundation of my git understanding :/
– Honey
Aug 10 at 15:00





See my last paragraph; I think @ElpieKay and I are saying the same thing. And I think you're not as confused as you think. You're correct that a push when the previous history is up-to-date is (from the remote's perspective) the mirror equivalent of a pull when the previous history is up-to-date. But outside the case when previous history is up-to-date, they differ: pull will merge your local changes with the new changes from remote, but push will be rejected.
– nvioli
Aug 10 at 15:03


push


pull


pull


push





added a link to an explanation of fast-forward merges.
– nvioli
Aug 10 at 15:05





when would a pull be rejected?
– Honey
Aug 10 at 16:56





@Honey: yes, a fast-forward operation isn't really a merge at all. A true merge can fail; in this case, a git pull that ran git merge has a nonzero exit status. Whether to call that a failed pull is an open question: half the pull (git fetch) worked, and half (git merge) failed.
– torek
Aug 10 at 18:31


git pull


git merge


git fetch


git merge






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

Firebase Auth - with Email and Password - Check user already registered

Dynamically update html content plain JS

How to determine optimal route across keyboard