如何从本地创建远程 Git 存储库？

How to create a remote Git repository from a local one?

提问by Nips

I have a local Git repository. I would like to make it available on a remote, ssh-enabled, server. How do I do this?

我有一个本地 Git 存储库。我想让它在支持 ssh 的远程服务器上可用。我该怎么做呢？

回答by Kerrek SB

I think you make a bare repository on the remote side, git init --bare, add the remote side as the push/pull tracker for your local repository (git remote add origin URL), and then locally you just say git push origin master. Now any other repository can pullfrom the remote repository.

我认为您在远程端创建了一个裸存储库，将远程端git init --bare添加为本地存储库 ( git remote add origin URL)的推/拉跟踪器，然后在本地您只需说git push origin master. 现在任何其他存储库都可以pull来自远程存储库。

回答by Binoy Babu

In order to initially set up any Git server, you have to export an existing repository into a new bare repository — a repository that doesn't contain a working directory. This is generally straightforward to do. In order to clone your repository to create a new bare repository, you run the clone command with the --bareoption. By convention, bare repository directories end in .git, like so:

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

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

This command takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone.

此命令单独使用 Git 存储库，没有工作目录，并专门为它创建一个目录。

Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols. Let's say you've set up a server called git.example.comthat you have SSH access to, and you want to store all your Git repositories under the /opt/gitdirectory. You can set up your new repository by copying your bare repository over:

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

$ scp -r my_project.git [email protected]:/opt/git

At this point, other users who have SSH access to the same server which has read-access to the /opt/gitdirectory can clone your repository by running

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

$ git clone [email protected]:/opt/git/my_project.git

If a user SSHs into a server and has write access to the /opt/git/my_project.gitdirectory, they will also automatically have push access. Git will automatically add group write permissions to a repository properly if you run the git init command with the --sharedoption.

如果用户通过 SSH 连接到服务器并对/opt/git/my_project.git目录具有写访问权限，他们也将自动具有推送访问权限。如果您运行带有该--shared选项的 git init 命令，Git 将自动正确地向存储库添加组写入权限。

$ ssh [email protected]
$ cd /opt/git/my_project.git
$ git init --bare --shared

It is very easy to take a Git repository, create a bare version, and place it on a server to which you and your collaborators have SSH access. Now you're ready to collaborate on the same project.

获取 Git 存储库、创建裸版本并将其放置在您和您的合作者具有 SSH 访问权限的服务器上非常容易。现在您已准备好在同一个项目上进行协作。

回答by user1804620

A note for people who created the local copy on Windows and want to create a corresponding remote repository on a Unix-line system, where text files get LF endings on further clones by developers on Unix-like systems, but CRLF endings on Windows.

给在 Windows 上创建本地副本并希望在 Unix 系统上创建相应远程存储库的人的注释，其中文本文件在类 Unix 系统上的开发人员进一步克隆时获得 LF 结尾，但在 Windows 上以 CRLF 结尾。

If you created your Windows repository before setting up line-ending translationthen you have a problem. Git's default setting is no translation, so your working set uses CRLF but your repository (i.e. the data stored under .git) has saved the files as CRLF too.

如果您在设置行尾翻译之前创建了 Windows 存储库， 那么您就会遇到问题。Git 的默认设置是没有翻译，因此您的工作集使用 CRLF，但您的存储库（即存储在 .git 下的数据）也将文件保存为 CRLF。

When you push to the remote, the saved files are copied as-is, no line ending translation occurs. (Line ending translation occurs when files are commited to a repository, not when repositories are pushed). You end up with CRLF in your Unix-like repository, which is not what you want.

当您推送到遥控器时，保存的文件将按原样复制，不会发生行尾转换。（行结束转换发生在文件提交到存储库时，而不是推送存储库时）。您最终会在类 Unix 存储库中使用 CRLF，这不是您想要的。

To get LF in the remote repository you have to make sure LF is in the local repository first, by re-normalizing your Windows repository. This will have no visible effect on your Windows working set, which still has CRLF endings, however when you push to remote, the remote will get LF correctly.

要在远程存储库中获取 LF，您必须首先通过重新规范化 Windows 存储库来确保 LF 位于本地存储库中。这对您的 Windows 工作集没有明显影响，它仍然具有 CRLF 结尾，但是当您推送到远程时，远程将正确获得 LF。

I'm not sure if there's an easy way to tell what line endings you have in your Windows repository - I guess you could test it by setting core.autocrlf=false and then cloning (If the repo has LF endings, the clone will have LF too).

我不确定是否有一种简单的方法可以告诉您 Windows 存储库中的行结尾 - 我想您可以通过设置 core.autocrlf=false 然后克隆来测试它（如果 repo 具有 LF 结尾，则克隆将具有LF也是）。

回答by V. Wheeler

There is an interesting difference between the two popular solutions above:

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

1. If you create the bare repository like this:

   cd     /outside_of_any_repo
   mkdir  my_remote.git
   cd     my_remote.git
   git init --bare
   

1. 如果您像这样创建裸存储库：

   cd     /outside_of_any_repo
   mkdir  my_remote.git
   cd     my_remote.git
   git init --bare
   

and then

进而

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

Then git sets up the configuration in 'original_repo' with this relationship:

然后 git 在“original_repo”中使用这种关系设置配置：

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

with the latter as the upstream remote. And the upstream remote doesn't have any other remotes in its configuration.

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

1. However, if you do it the other way around:

   (from in directory original_repo)
   cd ..
   git clone --bare original_repo  /outside_of_any_repo/my_remote.git
   

2. 但是，如果你反过来做：

   (from in directory original_repo)
   cd ..
   git clone --bare original_repo  /outside_of_any_repo/my_remote.git
   

then 'my_remote.git' winds up with its configuration having 'origin' pointing back to 'original_repo' as a remote, with a remote.origin.url equating to local directory path, which might not be appropriate if it is going to be moved to a server.

然后'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.)

虽然这个“远程”引用以后很容易在不合适的情况下删除，“original_repo”仍然必须设置为指向“my_remote.git”作为上游远程（或指向它要去的任何地方）分享自）。因此，从技术上讲，您可以通过方法 2 多执行几个步骤来获得相同的结果。但是#1 似乎是一种更直接的方法来创建源自本地的“中央裸共享存储库”，适用于移动到服务器，涉及的步骤更少。我认为这取决于您希望远程仓库扮演的角色。（是的，这与此处的文档冲突。）

Caveat: I learned the above (at this writing in early August 2019) by doing a test on my local system with a real repo, and then doing a file-by-file comparison between the results. But! I am still learning, so there could be a more correct way. But my tests have helped me conclude that #1 is my currently-preferred method.

警告：我通过在我的本地系统上使用真实的 repo 进行测试，然后对结果进行逐个文件的比较，了解了上述内容（在 2019 年 8 月上旬撰写本文时）。但！我还在学习，所以可能有更正确的方法。但我的测试帮助我得出结论，#1 是我目前首选的方法。

回答by Amirhossein72

A remote repository is generally a bare repository?—?a Git repository that has no working directory. Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it's just the Git data. In the simplest terms, a bare repository is the contents of your project's .git directory and nothing else.

远程仓库一般是裸仓库？——没有工作目录的 Git 仓库。由于存储库仅用作协作点，因此没有理由在磁盘上检出快照；这只是 Git 数据。用最简单的术语来说，裸存储库是项目 .git 目录的内容，没有别的。

You can make a bare git repository with the following code:

您可以使用以下代码创建一个裸 git 存储库：

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

One options for having a remote git repository is using SSH protocol:

拥有远程 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.

当自托管通过 SSH 时，Git 的通用传输协议。这是因为在大多数地方已经设置了对服务器的 SSH 访问？-？如果没有，很容易做到。SSH 也是一种经过身份验证的网络协议，因为它无处不在，所以通常很容易设置和使用。

要通过 SSH 克隆 Git 存储库，您可以指定如下ssh://URL：

$ git clone ssh://[user@]server/project.git

或者，您可以对 SSH 协议使用更短的类似 scp 的语法：

$ git clone [user@]server:project.git

在上述两种情况下，如果您没有指定可选的用户名，Git 会假定您当前登录的用户身份。

优点

使用 SSH 的优点很多。首先，SSH 相对容易设置？—？SSH 守护进程很常见，许多网络管理员都有使用它们的经验，许多操作系统发行版都设置了它们或有工具来管理它们。其次，通过 SSH 访问是安全的吗？——所有数据传输都经过加密和验证。最后，与 HTTPS、Git 和本地协议一样，SSH 是高效的，可以在传输数据之前使数据尽可能紧凑。

缺点

SSH 的不利方面是它不支持匿名访问您的 Git 存储库。如果您使用 SSH，人们必须能够 SSH 访问您的机器，即使是只读容量，这不会使 SSH 有利于人们可能只想克隆您的存储库以检查它的开源项目。如果您仅在公司网络中使用它，则 SSH 可能是您需要处理的唯一协议。如果您想允许对您的项目进行匿名只读访问，并且还想使用 SSH，则必须设置 SSH 以供您推送，但其他人可以从中获取其他内容。

For more information, check the reference: Git on the Server - The Protocols

有关更多信息，请查看参考： 服务器上的 Git - 协议

回答by Sam

You need to create a directory on a remote server. Then use "git init" command to set it as a repository. This should be done for each new project you have (each new folder)

您需要在远程服务器上创建一个目录。然后使用“git init”命令将其设置为存储库。这应该为您拥有的每个新项目（每个新文件夹）完成

Assuming you have already setup and used git using ssh keys, I wrote a small Python script, which when executed from a working directory will set up a remote and initialize the directory as a git repo. Of course, you will have to edit script (only once) to tell it server and Root path for all repositories.

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

Check here - https://github.com/skbobade/ocgi

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

回答by Alex Cio

Normally you can set up a git repo by just using the initcommand

通常，您只需使用以下init命令即可设置 git repo

git init

In your case, there is already a repo on a remote available. Dependent on how you access your remote repo ( with username inside the url or a ssh key which handles verification ) use just the clonecommand:

在您的情况下，遥控器上已经有一个 repo 可用。根据您访问远程存储库的方式（在 url 中使用用户名或处理验证的 ssh 密钥），仅使用以下clone命令：

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

There are also other ways to clone the repo. This way you call it if you have a ssh key setup on your machine which verifies on pulling your repository. There are other combinations of the url if you want to include your password and username inside to login into your remote repository.

还有其他方法可以克隆 repo。如果您的机器上设置了 ssh 密钥，可以通过这种方式调用它来验证拉取存储库。如果您想在其中包含密码和用户名以登录远程存储库，还有其他 url 组合。