I was attempting to resolve a conflict between master and my local branch using rebase. I resolved all conflicts and pushed. While checking to perform a pull request, I noticed there were commits I didn't recognize and want to undo the push. No merge or pull request made.
What I did:
$ git rebase master
$ Resolved all conflicts
$ git add --all
$ git rebase --continue
$ git push -u origin local_branch
If I don't merge/pull request, what happens to the git push?
If I don't merge/pull request, what happens to the git push?
By "pushing" you are simply putting a copy of your local branch in the remote repository. If you don't merge or pull then that branch will still exist in the remote repository. Nothing happens.
The solution?
You can delete the branch in the remote (origin) - I'm assuming nobody but you is using it. Or you can simply override it (WARNING: this will be destructive to your existing remote branch):
git push origin local_branch --force
If I don't merge/pull request, what happens to the git push?
Nothing "happens to it". It's already done. It is in the past, and is no more changeable than what you had for breakfast yesterday.
What git push does is have your Git call up another Git.
Your Git has commits and branch names, and their Git has commits and branch names. Your Git's branch names do not have to match their names—using the same name, such as master, is just a concession to human sanity—but if you and they have the same commits, you and they have the same raw hash IDs as well.
So, your Git has the "phone number" (URL) of some other Git saved in your Git's "address book" (.git/config entries), under the name origin. Using git push origin, you tell your Git: Dial up that other Git using the stored URL. The local_branch part of the git push then says:
local_branch.If the other Git doesn't have that commit yet, they will say yes please, send it on over and your Git will offer more commits. This goes on, commit by commit, until your Git reaches a commit they do have already. So now you've offered all your new (well, new-to-them) commits.
When the two Gits get to this point, of having agreed on which commits to send (along with any other necessary items that go with them), your Git packages those up:
Counting objects ...
Compressing ...
and then sends them over (see When I do "git push", what do the statistics mean? (Total, delta, etc.)). Their Git puts these in a temporary quarantine area—not something you normally have to care about, but in this Covid-19 era, a colorful fact.
Then, having sent over the commits, your Git sends over a nice polite request: If it's OK, please set your branch name ______ (insert name here) to ______ (insert hash ID here). The branch name, in this case, is local_branch—because that's the name you put in on your command line. The hash ID is the same hash ID that your name local_branch is storing.
Assuming they accept this request, they will create or update their branch name local_branch to point to the last commit that you have in your local_branch (and all the objects come out of quarantine and are now stored in their Git repository). They will report back that this was all OK. Your Git will now create or update your own origin/local_branch name to remember the hash ID they said they safely stored in their name local_branch.
Since you used git push -u, your Git will now set your newly-created or updated origin/local_branch name as the upstream setting of your own name local_branch.
Note that if you like, you can tell them to use a different name:
git push -u origin local_branch:fred_and_wilma
This tells your Git to locate the tip commit of your branch named local_branch, but when asking them to create or update their branch, to use the name fred_and_wilma instead. You should not normally do this as it just leads to confusion and heartache, plus of course it requires more typing at the command line.
That branch name now exists in that Git, and will sit there until someone—you, or anyone with permissions—tell that Git to change it in some way. If you, or they, specifically delete it, the name goes away. The commits themselves do not go away—not immediately, at least. But if that name was the only way to find the commits, that other Git will eventually delete those commits on its own.1
If someone else, with access to that other Git repository, looks at that Git repository after your git push, the someone-else here can get that name and those commits and store those commits in their (third) Git repository. So once you've sent commits to someone, you should, in general, assume that now, everyone has them. Even if you delete them off this second origin Git, some third, fourth, fifth, etc., Gits may have them now.
(If nobody else has any access to the origin Git, none of the above applies.)
1When using a site like GitHub or GitLab or BitBucket to host your origin Git, you can, if you've sent sensitive files by mistake, usually get an admin on the site to clear out commits faster than it would by default, and then they're really gone—but someone could still have copied them in the meantime.
