如何从本地创建远程 Git 存储库？
我有一个本地 Git 存储库。我想让它在远程、启用 ssh 的服务器上可用。我该怎么做？
I have a local Git repository. I would like to make it available on a remote, ssh-enabled, server. How do I do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我认为您在远程端创建了一个裸存储库，
git init --bare，将远程端添加为本地存储库的推/拉跟踪器（git remote add origin URLcode>），然后在本地你只需说git push origin master。现在任何其他存储库都可以从远程存储库中拉。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 saygit push origin master. Now any other repository canpullfrom the remote repository.为了最初设置任何 Git 服务器，您必须将现有存储库导出到新的裸存储库 - 不包含工作目录的存储库。这通常很容易做到。为了克隆存储库以创建新的裸存储库，请使用
--bare选项运行克隆命令。按照惯例，裸存储库目录以.git结尾，如下所示：此命令单独获取 Git 存储库（没有工作目录），并专门为其创建一个目录。
现在您已经有了存储库的裸副本，您所需要做的就是将其放在服务器上并设置协议。假设您已经设置了一个名为
git.example.com的服务器，您可以通过 SSH 访问该服务器，并且您希望将所有 Git 存储库存储在/opt/git目录。您可以通过复制裸存储库来设置新存储库：此时，对同一服务器具有 SSH 访问权限且对
/opt/git目录具有读取访问权限的其他用户可以克隆您的存储库。 通过 SSH 连接如果用户 到服务器并具有对
/opt/git/my_project.git目录的写访问权限，他们也将自动具有推送访问权限。如果您使用--shared选项运行 git init 命令，Git 将自动正确地向存储库添加组写入权限。获取 Git 存储库、创建裸版本并将其放置在您和您的协作者可以通过 SSH 访问的服务器上非常容易。现在您已准备好在同一个项目上进行协作。
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:This command takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone.
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: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 runningIf 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.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 在“original_repo”中设置具有以下关系的配置：
后者作为上游远程。并且上游遥控器的配置中没有任何其他遥控器。
但是，如果您以相反的方式进行操作：
那么“my_remote.git”最终的配置是“origin”作为远程指向“original_repo”，而remote.origin.url相当于本地目录路径，如果要移动到服务器，该路径可能不合适。
虽然“远程”引用如果不合适的话很容易在以后删除，但仍然必须将“original_repo”设置为指向“my_remote.git”作为上游远程（或指向它要去的任何地方）分享自）。因此从技术上讲，您可以使用方法 #2 通过更多步骤获得相同的结果。但#1 似乎是一种更直接的方法来创建源自本地的“中央裸共享存储库”，适合移动到服务器，涉及的步骤更少。我认为这取决于您希望远程存储库扮演的角色。 （是的，这与文档 此处。）
警告：我通过使用真实的存储库在本地系统上进行测试，然后逐个文件地进行测试，了解了上述内容（在 2019 年 8 月上旬撰写本文时）结果之间的比较。但！我还在学习中，所以可能有更正确的方法。但我的测试帮助我得出结论：#1 是我目前首选的方法。
There is an interesting difference between the two popular solutions above:
If you create the bare repository like this:
and then
Then git sets up the configuration in 'original_repo' with this relationship:
with the latter as the upstream remote. And the upstream remote doesn't have any other remotes in its configuration.
However, if you do it the other way around:
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.
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.)
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.
对于那些在 Windows 上创建本地副本并希望在 Unix 系统上创建相应的远程存储库的人来说，请注意，其中文本文件在类 Unix 系统上的开发人员进一步克隆时以 LF 结尾，但在 Windows 上以 CRLF 结尾。
如果您在设置行结束翻译之前创建了 Windows 存储库，那么您就会遇到问题。 Git 的默认设置是不翻译，因此您的工作集使用 CRLF，但您的存储库（即存储在 .git 下的数据）也将文件保存为 CRLF。
当您推送到远程时，保存的文件将按原样复制，不会发生行结束翻译。 （行结束翻译发生在文件提交到存储库时，而不是推送存储库时）。您最终会在类 Unix 存储库中得到 CRLF，这不是您想要的。
要在远程存储库中获取 LF，您必须首先确保 LF 在本地存储库中，通过 重新规范化您的 Windows 存储库。这对您的 Windows 工作集没有明显的影响，它仍然具有 CRLF 结尾，但是当您推送到远程时，远程将正确获得 LF。
我不确定是否有一种简单的方法可以告诉您 Windows 存储库中的行结尾 - 我想您可以通过设置 core.autocrlf=false 然后克隆来测试它（如果存储库有 LF 结尾，则克隆将具有LF 也）。
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.
If you created your Windows repository before setting up line-ending translation then 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.
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.
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.
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).
您可以使用以下代码创建一个裸 git 存储库：
拥有远程 git 存储库的一种选择是使用 SSH 协议：
欲了解更多信息，请查看参考：
服务器上的 Git - 协议
You can make a bare git repository with the following code:
One options for having a remote git repository is using SSH protocol:
For more information, check the reference:
Git on the Server - The Protocols
在当前代码文件夹中。
然后通过审核
In current code folder.
Then review by
您需要在远程服务器上创建一个目录。然后使用“git init”命令将其设置为存储库。应该为您拥有的每个新项目（每个新文件夹）执行此操作
假设您已经使用 ssh 密钥设置并使用了 git，我编写了一个小的 Python 脚本，当从工作目录执行时，它将设置远程并初始化目录作为 git 存储库。当然，您必须编辑脚本（仅一次）来告诉它所有存储库的服务器和根路径。
检查此处 - https://github.com/skbobade/ocgi
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)
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.
Check here - https://github.com/skbobade/ocgi
我有一个树莓派，我可以通过公钥通过 ssh 访问（不提示输入密码）。
在覆盆子上我做了
在我的笔记本电脑上我做了
就是这样
I have a raspberry where I can access via ssh through public key (no prompt for password).
On the raspberry I did
On my laptop I did
And that was it
通常，您只需使用 init 命令即可设置 git 存储库
。在您的情况下，远程可用的存储库已经存在。根据您访问远程存储库的方式（在 url 中使用用户名或处理验证的 ssh 密钥），仅使用
clone命令：还有其他方法来克隆存储库。如果您的计算机上设置了 ssh 密钥来验证拉取存储库，则可以通过这种方式调用它。如果您想在其中包含密码和用户名以登录远程存储库，则还有其他 url 组合。
Normally you can set up a git repo by just using the
initcommandIn 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: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.