我喜欢使用Git软件来推送提交，但我使用的那些（Gitbox，Github，SourceTree）都在向他们添加新的repo时要求本地回购。
事实是，我的回购在我的开发服务器而不是我的本地机器上。
那么Git软件可以使用远程Git仓库作为开发回购，然后将其推送到您的主仓库（例如Github或Bitbucket）吗？
否则，您似乎无法使用该软件，必须通过SSH使用命令行。
谢谢
一种不依赖于前端来支持直接操作远程仓库的解决方案是将远程安装为网络文件系统。如果您只有SSH访问远程计算机，您可以尝试通过SSHFS（在Linux上）或在Mac OS X上使用FUSE使用OSXFUSE。或者根据您的首选项和设置，您可以使用SMB，NFS，DAV或其他网络文件系统。
我在评论中提到的另一种方法是将网络文件系统从开发机器导出到服务器。我这样做是为了让我可以同时在多台机器上安装我当前的工作副本，并且即使我没有连接到服务器，我仍然可以使用本地工作副本。
你写：
我很惊讶git软件无法处理远程回购作为工作版本。
大多数Git GUI通过调用git命令来完成他们的一些工作。为了让它们支持远程操作，核心Git也必须这样做。它是用C和shell脚本混合编写的;所有这些都必须重写以应对远程文件。
文本编辑器工作更容易;它在你打开时读取一个文件，在保存时写入，而Git在commit这样的单个操作过程中读取和写入许多文件。
网络文件系统意味着所有工具（Git和其他工具）都可以在您的远程文件上运行。不是在每个应用程序中构建一个层来支持网络文件访问，而是在内核中（或通过FUSE）执行它，然后只需将其视为本地文件系统，就可以免费为每个应用程序提供支持。
记住，Git是一个DVCS。您没有连接到远程服务器来提交内容的事实是设计的。
你想要做的是拥有本地Git repos，将代码推送到集成服务器（实际运行代码的服务器）。这就像部署一样，只有部署到测试服务器而不是生产。
这通常通过拥有一个共享的Git存储库来实现。这个回购should be bare。除了裸共享仓库之外，你还需要一个共享Git仓库的非裸机克隆，它将作为你的Apache docroot。
当共享repo收到提交时，它将使docroot repo执行git pull。
这可以通过在共享仓库上使用post-receive hooks来实现。
docroot repo在特定的分支上签出（让我们说develop）。因此，即使您将内容提交给其他分支并推送它们，服务器也不会受到影响。
这允许您设置多个部署存储库，因此您可以将另一个分支prod与其中一个实际更新生产代码的分支相关联。
它还允许您在完全不部署的共享分支上存储不完整/正在进行的工作，以便您知道您在笔记本电脑上工作的东西在共享存储库上是安全的，即使它可以' t被发送到测试服务器，因为它不完整，会破坏测试服务器，使其他人无法工作或什么的。
This article详细介绍了如何设置所有这些。我以前做过，效果很好。
我找到了一个简单的方法：在传输（FTP客户端）中有一个选项'将收藏夹安装为磁盘'。 SourceTree可以按预期使用此“虚拟”磁盘。
但有一个限制：只有在完成代码中的所有更改并准备好进行提交/推送后才能挂载磁盘并启动SourceTree，如果在处理代码时保持SourceTree和ssh磁盘安装，它将无法工作。由于某种原因，由Transmit安装的磁盘不会实时更新文件内容，而是仅在卸载/挂载操作之后。
大约一年前我遇到了这个问题 - 遗憾的是我找不到任何一致，可靠的答案。我用谷歌搜索了几个星期，认为这是我的搜索条款没有成功 - 尝试每一个方向。
[我们的设置是每个开发人员都有他们自己的开发服务器 - 将它们与机器分开意味着可以在任何地方开发站点，开发服务器可以设置为与实时环境完全相同，系统管理员可以保持升级和备份 - 我完全看到了为工作机器提供单独的开发服务器的优势，其中一个缺点是没有git应用程序！]
依赖于文件安装或欺骗您的计算机的所有东西都认为远程驱动器是本地的，这对于一般文件浏览来说是好的，但是当连接断断续续时，Git应用程序往往会脱落。其他时候你必须以某种方式做事，只是为了看到git status
我知道这不是你想听到的答案，因为我刚才处于你的情况并且确切地知道你的感受，但你能做的最好的事情就是在命令行上使用git。
我讨厌成为那些命令行之一更好的Stack Overflow回答者，但是在这种情况下我找不到任何可以解决的问题，每天都要由多个开发人员全天使用。
我当时也反对它，我更喜欢更漂亮，更易于使用的UI，但是自从学习命令行和git之后，我再也没有回头。当我在家里开始自己的项目时，我发现自己在任何应用程序上使用终端，因为我发现其中很多都令人困惑！
它不仅有助于您的命令行信心，但自从使用终端以来，我的Git知识已经提高了十倍，因为应用程序经常隐藏很多事情。
7年后，目标是让Git能够通过VFS for Git使用虚拟磁盘。
Git虚拟文件系统（以前称为GVFS）是一个开源系统，它使Git能够在企业级运营。 它使得使用和管理大量Git存储库成为可能。
VFS for Git虚拟化Git存储库下的文件系统，以便Git工具看到看起来像普通存储库的东西，实际上，这些文件实际上并不存在于磁盘上。 VFS for Git仅在需要时下载文件。
这不是Git本身的一部分，但是：
为此，Git 2.22（2019年第二季度）将通过引入一个新的钩子“post-index-change”来帮助管理这样的虚拟磁盘，当磁盘上的索引文件发生变化时，它将被调用：这可以帮助例如虚拟化工作树实现。
见commit 1956ecd的Ben Peart (benpeart)（2019年2月15日）。
（由Junio C Hamano -- gitster --合并于commit 5795a75，2019年4月25日）
read-cache：添加post-index-change钩添加一个在
post-index-change中写入索引后调用的do_write_locked_index()钩子。此挂钩主要用于通知，并且不会影响触发索引写入的git命令的结果。
钩子被传递一个标志，指示工作目录是否被更新，以及一个标志，指示
skip-worktree位是否可以更改。 这些标志使钩子能够优化其对索引更改通知的响应。