我认为你在远程端创建一个裸库，git init——bare，添加远程端作为本地存储库的推/拉跟踪器(git remote add origin URL)，然后在本地输入git push origin master。现在任何其他存储库都可以从远程存储库中提取。

您需要在远程服务器上创建目录。然后使用“git init”命令将其设置为存储库。对于每个新项目(每个新文件夹)都应该这样做

假设你已经使用ssh键设置和使用了git，我写了一个小的Python脚本，当从一个工作目录执行时，它将设置一个远程目录，并将该目录初始化为一个git repo。当然，您必须编辑脚本(只有一次)来告诉它所有存储库的服务器和根路径。

点击这里查看- https://github.com/skbobade/ocgi

远程存储库通常是一个裸存储库——Git存储库 没有工作目录。因为存储库仅用于 对于协作点，没有理由检查快照 在磁盘上;它只是Git数据。用最简单的话来说，就是赤裸 Repository是项目的.git目录的内容 什么都没有。

你可以用下面的代码创建一个git仓库:

$ git clone --bare /path/to/project project.git

有一个远程git存储库的选项是使用SSH协议:

A common transport protocol for Git when self-hosting is over SSH. This is because SSH access to servers is already set up in most places — and if it isn’t, it’s easy to do. SSH is also an authenticated network protocol and, because it’s ubiquitous, it’s generally easy to set up and use. To clone a Git repository over SSH, you can specify an ssh:// URL like this: $ git clone ssh://[user@]server/project.git Or you can use the shorter scp-like syntax for the SSH protocol: $ git clone [user@]server:project.git In both cases above, if you don’t specify the optional username, Git assumes the user you’re currently logged in as. The Pros The pros of using SSH are many. First, SSH is relatively easy to set up — SSH daemons are commonplace, many network admins have experience with them, and many OS distributions are set up with them or have tools to manage them. Next, access over SSH is secure — all data transfer is encrypted and authenticated. Last, like the HTTPS, Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it. The Cons The negative aspect of SSH is that it doesn’t support anonymous access to your Git repository. If you’re using SSH, people must have SSH access to your machine, even in a read-only capacity, which doesn’t make SSH conducive to open source projects for which people might simply want to clone your repository to examine it. If you’re using it only within your corporate network, SSH may be the only protocol you need to deal with. If you want to allow anonymous read-only access to your projects and also want to use SSH, you’ll have to set up SSH for you to push over but something else for others to fetch from.

欲了解更多信息，请查看参考文献: 服务器上的Git -协议

我认为你在远程端创建一个裸库，git init——bare，添加远程端作为本地存储库的推/拉跟踪器(git remote add origin URL)，然后在本地输入git push origin master。现在任何其他存储库都可以从远程存储库中提取。

上面两种流行的解决方案之间有一个有趣的区别:

如果你像这样创建裸库: cd / outside_of_any_repo mkdir my_remote.git cd my_remote.git Git初始化

然后

cd  /your_path/original_repo
git remote add origin /outside_of_any_repo/my_remote.git
git push --set-upstream origin master

然后git在'original_repo'中设置如下关系:

original_repo origin --> /outside_of_any_repo/my_remote.git/

后者作为上游遥控器。上游远程在其配置中没有任何其他远程。

然而，如果你反过来做: (from original_repo目录) cd . . Git克隆——bare original_repo /outside_of_any_repo/my_remote.git

然后“my_remote。Git '最终的配置是将'origin'指向'original_repo'作为一个远程，并将remote.origin.url等同于本地目录路径，如果要将其移动到服务器上，这可能不合适。

While that "remote" reference is easy to get rid of later if it isn't appropriate, 'original_repo' still has to be set up to point to 'my_remote.git' as an up-stream remote (or to wherever it is going to be shared from). So technically, you can arrive at the same result with a few more steps with approach #2. But #1 seems a more direct approach to creating a "central bare shared repo" originating from a local one, appropriate for moving to a server, with fewer steps involved. I think it depends on the role you want the remote repo to play. (And yes, this is in conflict with the documentation here.)

注意:我是在2019年8月初写这篇文章的时候，通过在我的本地系统上用一个真正的repo进行测试，然后在结果之间逐个文件进行比较，才了解到上述情况的。但是!我还在学习中，应该会有更正确的方法。但我的测试帮助我得出结论，#1是我目前首选的方法。

在当前代码文件夹中。

git remote add origin http://yourdomain-of-git.com/project.git
git push --set-upstream origin master

然后通过

git remote --v