On a high level, I understand that it's a good practice to git pull(and manually merge conflicts if any) before git-push. I am working in an enterprise setting. My questions are:
(1) Can I do git-push without first git-pull?. Is it not allowed at all or github can be configured (by admin) to behave in a certain way -- say to crib during push that pull was not done or to not crib at all..
(2) Following up on (1) question, say I did do git pull first, but then I didn't really merge anything gracefully and just overwrote in local files and then try to git push, will this go through?. I mean for namesake/record, I did git-pull, though I didn't honor it...what prevents a user from doing this (if at all).
(3) Is there a way to configure a branch so that pushes to the branch only happen thru pull request and not directly (say from command line etc). Is there a notion of something like branch owner who can configure whether to allow direct push or not?.
(4) I understand that some of this could be tried by running some experiments, but that would only give me some idea on my current setup. I want to understand what is the standard behavior and what all can be customized...
Addressing your questions one by one:
(1) Can I do git-push without first git-pull?. Is it not allowed at all or github can be configured (by admin) to behave in a certain way -- say to crib during push that pull was not done or to not crib at all..
Pushing without pulling first is not necessarily a problem. It is only a problem if others pushed changes to your target branch, and you have not pulled these changes. In that case the push will be denied. The error message you will get will be something like:
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to XXX
If you want to push without pulling first, this error can be overriden using git push -f (though the server may be configured to still reject your push). However, this is rarely advisable, as you will then overwrite changes others have made. For details (and why not to do this) see e.g. How do I properly force a Git push? .
(2) Following up on (1) question, say I did do git pull first, but then I didn't really merge anything gracefully and just overwrote in local files and then try to git push, will this go through?. I mean for namesake/record, I did git-pull, though I didn't honor it...what prevents a user from doing this (if at all).
Yes, it will go through, and no, there is nothing in git preventing this. While git can indeed tell (to some extent) whether you integrated or discarded changes by others when merging, there is no way for git to tell whether this is right. However, your changes (including your merge) will be visible in git's history, so your colleagues can complain to you later :-).
(3) Is there a way to configure a branch so that pushes to the branch only happen thru pull request and not directly (say from command line etc). Is there a notion of something like branch owner who can configure whether to allow direct push or not?.
In core git itself, there is no such thing. However, when hosting a central repository for a project on a server, the server will usually not just run git, but a hosting service application that supports git (such as Gitlab, Bitbucket or Gitea). These hosting applications usually support restrictions on who can push where and when.
(4) I understand that some of this could be tried by running some experiments, but that would only give me some idea on my current setup. I want to understand what is the standard behavior and what all can be customized...
I hope I have given some insight. The standard behaviour can usually be found in the documentation.