【问题标题】:How can I check the status of a remote Git repository?如何检查远程 Git 存储库的状态?
【发布时间】:2013-09-20 17:13:25
【问题描述】:

我有一个远程 Git 存储库,我可以通过 SSH 从本地存储库推送/拉取该存储库。

我可以使用 Git status 命令检查本地存储库中未跟踪/未暂存的文件。我如何对远程存储库做同样的事情?

请注意,我不是在寻找本地提交和远程提交之间的差异。

【问题讨论】:

  • 您要检查,其他人签入/添加了哪些更改?
  • 如果你可以推送到它,它通常应该是一个--bare repo,所以永远不会有任何工作在它上面完成,而服务器上的git status 应该永远不会有任何东西可以报告第一名。
  • 也许这会有所帮助:stackoverflow.com/a/18760795/683080
  • @Viji 好吧,我有兴趣在远程仓库中查找尚未暂存的文件。其他人添加的更改应显示在提交差异中。
  • 在服务器上,查看 repo。如果它只包含 git 目录,那么它是空的。 (从技术上讲,如果git config --get --bool core.baretrue 是裸露的。但它往往非常明显:ls 在非裸仓库中显示工作文件,ls 在裸仓库中显示您在@987654329 时看到的内容@ 在工作树中。)

标签: git


【解决方案1】:

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

注意事项:

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

【讨论】:

    【解决方案2】:

    如果你有一个 Git 远程存储库,你可以通过 SSH git push 访问它,它通常应该1是一个--bare 存储库(请参阅description of setting up a bare repository on a server in the on-line Git book)。裸存储库没有任何地方可以对其进行任何工作。这意味着git status 没有什么要报告的——事实上,如果你有一个裸存储库和cd,你会收到一条错误消息:它需要一个工作目录才能报告任何内容。)

    裸存储库的技术定义是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
    

    但是通过检查通常很明显:如果您的克隆说来源是ssh://some.host/some/dir/repo,并且您可以ssh some.hostcd /some/dir/repols,那么“裸”克隆看起来很像@ 的内容非裸克隆上的987654334@目录:

    $ 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
    

    对比:

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

    (裸克隆缺少一些在非裸克隆中进行普通 Git 工作的文件,但它们显然是相关的。)


    1可以推送到非裸存储库——这只是个坏主意。如果你查看自己非裸克隆的.git/config(或者使用更官方的接口git config --get receive.denyCurrentBranch),一般会看到这样的内容:

    [receive]
            denyCurrentBranch = warn
    

    此处的值可以是refusetruewarnfalseignore 中的任何一个。大多数值都设置为push 只有在推送到“当前”分支之外的某个分支other 时才被接受。

    这里的问题是......好吧,假设您登录到其他人推送的服务器上。你瞧,你cd /some/dir/repo 还有所有这些工作文件。

    git checkout zorg,编辑出租车司机的数量,git commit 结果非常诱人。但是当其他人在其他地方编辑同一个分支并提交然后git push-es 在你中间做类似的事情时会发生什么?

    如果他/她在您开始 commit 之前完成了他/她的推送,那么您就会陷入混乱。通常,你们俩都在服务器以外的系统上执行此操作,并且首先推送的人“获胜”,而另一个人获得失败的“非快进”推送并且知道获取和(合并或重新设置)(@ 987654351@ 或 git pull --rebase 或其他)。

    但是你已经在服务器上,所以你不能使用正常的工作流程。事实上,首先要让工作树保持最新是很困难的:你可以用钩子来做到这一点,但是如果你有钩子 git reset --hard 来更新工作树,它会丢弃任何人所做的任何工作2

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

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

    (根据 cmets 的要求,这是“答案”形式的两个 cmets。由于这里有更多空间,我将它们扩展了一点。)

    【讨论】:

      【解决方案3】:

      这可能不是您正在寻找的内容,但我到这里询问了 Google 的类似问题。我想知道的是“相对于我的本地主人,我的遥控器目前在哪里。

       git log
      

      正是我所需要的。

      commit 7bf74892162713b87a19c6194c8041c9bbf96552 (HEAD -> master, origin/master)
      Author: Andy Reilly <andy@blah.com>
      Date:   Tue Nov 9 18:46:16 2021 -0800
      
      fixed data validation lock on condition column in upload spreadsheet
      
      commit 8462456d5fe6bcc11acbf89bca949f15faef0424 (training-db/master)
      Author: Andy Reilly <andy@blah.com>
      Date:   Mon Nov 8 12:28:02 2021 -0800
      
      added todo for future setup
      
      commit 1cf4a93d419c4ccc1d1f5ac9203edd2b9cefafa4
      Author: Andy Reilly <andy@blah.com>
      Date:   Mon Nov 8 11:15:56 2021 -0800
      
      added uniqueness to tenant for category names so accidental rerun of initial setup does not create duplicates
      
      commit 28f2d5a2c4ca869ebdb086696c97554587592e27 (multi-tenant/master)
      Author: Andy Reilly <andy@blah.com>
      Date:   Sat Nov 6 18:32:09 2021 -0700
      

      所以知道我知道我的训练服务器落后了一个提交,而我的生产服务器落后了两个提交。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2010-09-11
        • 2014-08-12
        • 1970-01-01
        • 2018-06-15
        • 2014-06-13
        • 1970-01-01
        • 2011-03-03
        • 2013-01-04
        相关资源
        最近更新 更多