在当前代码文件夹中。

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

然后通过

git remote --v

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

如果你像这样创建裸库: 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 init——bare，添加远程端作为本地存储库的推/拉跟踪器(git remote add origin URL)，然后在本地输入git push origin master。现在任何其他存储库都可以从远程存储库中提取。

为了最初设置任何Git服务器，您必须将现有的存储库导出到一个新的裸存储库—一个不包含工作目录的存储库。这通常很简单。为了克隆存储库以创建一个新的裸存储库，可以运行带有——bare选项的clone命令。按照惯例，裸存储库目录以.git结尾，如下所示:

$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/

这个命令单独获取Git存储库，没有工作目录，并单独为它创建一个目录。

现在您已经有了存储库的一个裸副本，您所需要做的就是将它放到服务器上并设置协议。假设您已经设置了一个名为git.example.com的服务器，您可以通过SSH访问该服务器，并且您希望将所有Git存储库存储在/opt/ Git目录下。你可以通过复制你的裸存储库来建立新的存储库:

$ scp -r my_project.git user@git.example.com:/opt/git

此时，对同一台服务器具有读/opt/git目录访问权限的其他用户可以通过运行命令克隆您的存储库

$ git clone user@git.example.com:/opt/git/my_project.git

如果一个用户ssh到一个服务器，并且对/opt/git/my_project有写权限。Git目录下，他们也会自动拥有推送访问权限。如果你使用——shared选项运行Git init命令，Git会自动为存储库添加组写权限。

$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared

获取Git存储库，创建一个裸版本，并将其放在您和您的合作者可以SSH访问的服务器上，这是非常容易的。现在你已经准备好在同一个项目上合作了。

通常你只需要使用init命令就可以建立一个git repo

git init

在您的情况下，已经有一个回购的远程可用。根据您如何访问远程repo (url内的用户名或处理验证的ssh密钥)，只使用clone命令:

git clone git@[my.url.com]:[git-repo-name].git

还有其他方法可以克隆回购。如果您在计算机上设置了ssh密钥，在提取存储库时进行验证，则可以使用这种方法调用它。如果您希望在其中包含密码和用户名以登录到远程存储库，则该url还有其他组合。

远程存储库通常是一个裸存储库——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 -协议