如何检查远程 Git 存储库的状态？

How to check status of remote Git repository?

提问by John

I have a remote Git repository to which I can push/pull from a local repo via SSH. I can use the Git statuscommand to check the untracked/unstaged files on the local repo. How do I do the same with the remote repo? Please note that I'm not looking at finding the differences between the local commit and the remote commit.

我有一个远程 Git 存储库，我可以通过 SSH 从本地存储库推送/拉取到该存储库。我可以使用 Gitstatus命令检查本地存储库上未跟踪/未暂存的文件。我如何对远程仓库做同样的事情？请注意，我不是在寻找本地提交和远程提交之间的差异。

采纳答案by torek

(As requested in comments, here's the two comments in "answer" form. I've expanded them a bit since there is more space here.)

（根据评论中的要求，这里是“回答”形式的两条评论。由于这里有更多空间，我对它们进行了一些扩展。）

If you have a git remote repo to which you can git pushvia SSH, it should generally¹be a --barerepo (see the description of setting up a bare repo on a server in the on-line git book). A bare repo has no place in which to do any work on it. This means git statushas nothing to report—in fact, if you have a bare repo and cdto it, you get an error message: it needs a work directory in order to report anything.)

如果你有一个远程Git回购协议，你可以git push通过SSH，但通常它的¹是一个--bare回购协议（见在上线的git书建立一个服务器上的裸回购的描述）。一个裸仓库没有地方可以做任何工作。这意味着git status没有什么可报告的——事实上，如果你有一个裸仓库cd，你会收到一条错误消息：它需要一个工作目录才能报告任何内容。）

The technical definition of a bare repo is one in which git config --get --bool core.bareprints true. I have a non-bare repo in /tmp/tto start, here:

裸仓库的技术定义是在其中git config --get --bool core.bare打印true. 我有一个非裸回购/tmp/t开始，在这里：

$ cd /tmp/t; git config --get --bool core.bare
false
$ cd /tmp; git clone --bare t bare.t.git
Cloning into bare repository 'bare.t.git'...
done.
$ cd bare.t.git
$ git config --get --bool core.bare
true

But it's usually obvious from inspection: if your clone says that the origin is ssh://some.host/some/dir/repo, and you can ssh some.hostand cd /some/dir/repoand ls, a "bare" clone looks much like the contents of the .gitdirectory on the non-bare clone:

但它通常是显而易见的检查：如果你的克隆说，起源是ssh://some.host/some/dir/repo，你可以ssh some.host和cd /some/dir/repo和ls，一个“裸”克隆看起来很像的内容.git在非裸克隆目录：

$ cd /tmp/t; ls .git
COMMIT_EDITMSG  ORIG_HEAD       description     index           objects
FETCH_HEAD      branches        gitk.cache      info            packed-refs
HEAD            config          hooks           logs            refs

vs:

对比：

$ cd /tmp/bare.t.git; ls
HEAD            config          hooks           objects         refs
branches        description     info            packed-refs

(the bare clone lacks a few of the files made doing ordinary git work in the non-bare one, but they are clearly related).

（裸克隆缺少一些在非裸克隆中执行普通 git 工作的文件，但它们显然是相关的）。

---

---

¹It's possible to push to non-bare repos—it's just a bad idea. If you look at your own non-bare clone's .git/config(or use the more official interface, git config --get receive.denyCurrentBranch), you will generally see something like this:

¹可以推送到非裸存储库——这只是一个坏主意。如果您查看自己的非裸克隆.git/config（或使用更官方的界面，git config --get receive.denyCurrentBranch），您通常会看到如下内容：

[receive]
        denyCurrentBranch = warn

The value here may be any of refuse, true, warn, false, or ignore. Most values set things up so that pushis only accepted if the push is to some branch otherthan the "current" branch. The problem here is ... well, suppose you're logged in on the server to which other people push. And lo, you cd /some/dir/repoand there are all these work files. It's quite tempting to git checkout zorg, edit the number of taxi drivers, and git committhe result. But what happens when someone else is editing the same branch elsewhere, and commits and then git push-es in the middle of you doing something similar? If he finishes his push before you start your commit, you have kind of a mess. Normally, both of you do this on systems other than the server, and whoever pushes first "wins" and the other person gets a failed "non fast forward" push and knows to fetch-and-(merge-or-rebase) (git pullor git pull --rebaseor whatever). But you're already on the server, so you can't use the normal work flow. In fact, it's tough to keep the work tree up-to-date in the first place: you can do this with a hook, but if you have the hook git reset --hardto update the work tree, it throws away any work anyone was doing.²

这里的值可以是任意的refuse，true，warn，false，或ignore。最值设置的东西，以便push如果推的是一些分支机构只能接受其他比“当前”分支。这里的问题是……好吧，假设您登录了其他人推送的服务器。瞧，你cd /some/dir/repo还有所有这些工作文件。git checkout zorg编辑出租车司机的数量和git commit结果非常诱人。但是当其他人在别处编辑同一个分支，然后提交然后git push-es 在你中间做类似的事情时会发生什么？如果他在你开始之前完成了他的推动commit，你有点乱。通常，你们俩都在服务器以外的系统上执行此操作，谁先“获胜”，而另一个人则获得失败的“非快进”推送，并且知道要获取和（合并或变基）（git pull或git pull --rebase管他呢）。但是您已经在服务器上，因此无法使用正常的工作流程。事实上，一开始就很难保持工作树是最新的：你可以用一个钩子来做到这一点，但如果你有git reset --hard更新工作树的钩子，它就会丢弃任何人正在做的任何工作。²

It's easier to just avoid the problem entirely: decree that there is no work tree, that this is to be a --bareclone. All the temptations and problems vanish.

完全避免这个问题更容易：规定没有工作树，这是一个--bare克隆。所有的诱惑和问题都消失了。

²At one job, I inherited a setup that did just that (git reset --hardin a post-receive hook, and also at 6 hour intervals via cron). It caused a lot of confusion at least once every few months. Unfortunately, the server and directory paths were hard-wired lots of places, making it hard to fix, too (and this particular issue was low priority). We just lived with it.

²在一份工作中，我继承了一个设置，就是这样做的（git reset --hard在接收后挂钩中，并且通过 6 小时间隔cron）。它至少每隔几个月就会引起很多混乱。不幸的是，服务器和目录路径在很多地方都是硬连线的，因此也很难修复（这个特殊问题的优先级很低）。我们只是忍受它。

回答by Boi Sletterink

git fetch --dry-run --verbosemay show what you need. Example:

git fetch --dry-run --verbose可能会显示您需要的内容。例子：

# Before a remote update:
user@localhost:~/build/demo/myrepo$ git fetch --dry-run --verbose
From https://gitserver.local/git/myrepo
 = [up to date]      master     -> origin/master

# After a remote update:
user@localhost:~/build/demo/myrepo$ git fetch --dry-run --verbose
POST git-upload-pack (328 bytes)
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 8 (delta 6), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
From https://gitserver.local/git/myrepo
   83619a7..67ea28b  master     -> origin/master

Caveats:

注意事项：

• The exit code does not reflect your local repo being in sync with the remote repo; it only reflects on the action itself being successful or not.
• If your local repo contains newer changes than the remote repo, git fetch still considers your local repo up to date. Maybe git push --dry-runhelps for this case.

• 退出代码并不反映您的本地存储库与远程存储库同步；它只反映行动本身是否成功。
• 如果您的本地存储库包含比远程存储库更新的更改，则 git fetch 仍会认为您的本地存储库是最新的。也许git push --dry-run对这种情况有帮助。