(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.
发布评论
评论（1）
一一解答您的疑问：
先推而不拉不一定是问题。只有当其他人将更改推送到您的目标分支，而您尚未拉取这些更改时，这才是问题。在这种情况下，推送将被拒绝。您将收到的错误消息类似于：
如果您想在不先拉取的情况下进行推送，可以使用 git push -f 覆盖此错误（尽管服务器可能配置为仍然拒绝您的推送） 。但是，这很少是可取的，因为您将覆盖其他人所做的更改。有关详细信息（以及为什么不这样做），请参阅例如 我如何正确强制 Git 推送？ 。
是的，它会通过，不，git 中没有任何东西可以阻止这一点。虽然 git 确实可以（在某种程度上）判断您在合并时是否集成或丢弃了其他人的更改，但 git 无法判断这是否正确。但是，您的更改（包括合并）将在 git 的历史记录中可见，因此您的同事稍后可以向您投诉:-)。
在核心 git 本身中，没有这样的东西。然而，当在服务器上托管项目的中央存储库时，服务器通常不仅运行 git，还会运行支持 git 的托管服务应用程序（例如 Gitlab、Bitbucket 或 Gitea）。这些托管应用程序通常支持限制谁可以在何时何地推送。
我希望我已经给出了一些见解。标准行为通常可以在文档中找到。
Addressing your questions one by one:
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:
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? .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 :-).
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.
I hope I have given some insight. The standard behaviour can usually be found in the documentation.