Git 服务器像 GitHub？

Git Server Like GitHub?

提问by skaz

I am a long time Subversion user that is going to try Git. I have read some about it and understand the distributed nature - I can see a lot of the benefits.

我是 Subversion 的长期用户，打算尝试 Git。我已经阅读了一些关于它并了解分布式性质的内容 - 我可以看到很多好处。

However, I do like the idea of a central server that can take on the role of backups, system of record, etc, while still using Git for my local branching and sharing. I am not doing an open source project, so I can't use Github (without paying), so my question really is: what is a best practice way to run a local git server?

但是，我确实喜欢中央服务器的想法，它可以承担备份、记录系统等的角色，同时仍然使用 Git 进行本地分支和共享。我不是在做开源项目，所以我不能使用 Github（不付费），所以我的问题是：运行本地 git 服务器的最佳实践方法是什么？

I realize this may be against the standard Git usage pattern, but it will be useful for my project. Any concerns that I may have overlooked are always welcome, however.

我意识到这可能违反了标准的 Git 使用模式，但它对我的项目很有用。然而，我可能忽略的任何问题总是受欢迎的。

Thanks!

谢谢！

采纳答案by Chris Eberle

You can just set up an ssh server and run a central repository there. All developers then simply agree (as a matter of policy) to push to the server when they are done making commits. This is the usage pattern at my workplace. Very CVS and SVN-like.

您可以只设置一个 ssh 服务器并在那里运行一个中央存储库。然后，所有开发人员都同意（作为政策问题）在完成提交后推送到服务器。这是我工作场所的使用模式。非常像 CVS 和 SVN。

1. Find somewhere to put the repository (/var/gitrootfor example).
2. Create a new repo (mkdir project.git && cd project.git && git init --bare --shared=group).
3. Then on your client, clone the remote repo (git clone ssh://yourserver.com/var/gitroot/project.git && cd project)
4. add some files (git add README)
5. commit (git commit -m "Initial import"),
6. push (git push origin master)

1. 找个地方放存储库（/var/gitroot例如）。
2. 创建一个新的存储库 ( mkdir project.git && cd project.git && git init --bare --shared=group)。
3. 然后在您的客户端上，克隆远程 repo ( git clone ssh://yourserver.com/var/gitroot/project.git && cd project)
4. 添加一些文件 ( git add README)
5. 提交 ( git commit -m "Initial import"),
6. 推 ( git push origin master)

This should set things up for you.

这应该为您做好准备。

回答by Craig

Gitorious is an open source web interface to git that you can run on your own server, much like github:

Gitorious 是一个开源的 git web 接口，你可以在自己的服务器上运行，很像 github：

http://getgitorious.com/

http://getgitorious.com/

Update:

更新：

http://gitlab.org/is another alternative now as well.

http://gitlab.org/现在也是另一种选择。

Update 2:

更新 2：

Gitorious has now joined with GitLab

Gitorious 现已加入 GitLab

回答by Plamen Nikolov

Try GitLab

试试GitLab

The best git GUI tool i have ever used. It is very similar to GitHub.

我用过的最好的 git GUI 工具。它与 GitHub 非常相似。

It is open source (MIT License) and is the most installed git management software with over 25.000 installation. It has monthly releases and an active community with over 375 contributors. You can have unlimited private, internal and public repositories on your own server. It is a Ruby on Rails app that runs on most Unix platforms.

它是开源的（MIT 许可证），是安装次数最多的 git 管理软件，安装量超过 25.000。它每月发布一次，活跃的社区拥有超过 375 名贡献者。您可以在自己的服务器上拥有无限的私有、内部和公共存储库。它是一个运行在大多数 Unix 平台上的 Ruby on Rails 应用程序。

回答by stigkj

If you don't mind getting down and dirty with the command line, gitoliteis an absolute treat when working in a corporate environment where you need to set differenct access rights on different repositories. It is sort of a newer version of gitosis mentioned by @Chris.

如果您不介意对命令行感到厌烦，那么在需要在不同存储库上设置不同访问权限的企业环境中工作时，gitolite绝对是一种享受。这是@Chris 提到的更新版本的 gitosis。

Here is the summary from the author's web site:

以下是作者网站的摘要：

Gitolite lets you use a single user on a server to host many git repositories and provide access to many developers, without having to give them real userids on or shell access to the server. The essential magic in doing this is ssh's pubkey access and the authorized_keys file, and the inspiration was an older program called gitosis.

Gitolite can restrict who can read from (clone/fetch) or write to (push) a repository. It can also restrict who can push to what branch or tag, which is very important in a corporate environment. Gitolite can be installed without requiring root permissions, and with no additional software than git itself and perl.

Gitolite 允许您在服务器上使用单个用户来托管多个 git 存储库并为许多开发人员提供访问权限，而无需在服务器上为他们提供真实的用户 ID 或 shell 访问权限。这样做的基本魔法是 ssh 的 pubkey 访问和 authorized_keys 文件，灵感来自一个名为 gitosis 的旧程序。

Gitolite 可以限制谁可以读取（克隆/获取）或写入（推送）存储库。它还可以限制谁可以推送到什么分支或标签，这在公司环境中非常重要。Gitolite 无需 root 权限即可安装，除了 git 本身和 perl 之外，无需其他软件。

It has quite a comprehensive feature set, but one thing I like very much, is that all of the day to day configuration editing is done through a special git repository. That is, adding a user is just

它具有相当全面的功能集，但我非常喜欢的一件事是，所有日常配置编辑都是通过一个特殊的 git 存储库完成的。也就是说，添加一个用户只是

• Add user to configuration file
• Add the user's ssh key
• Commit the change
• Push it to gitolite
• Voila, the configuration is live!

• 将用户添加到配置文件
• 添加用户的ssh密钥
• 提交更改
• 把它推到 gitolite
• 瞧，配置已上线！

And when needing to look at the code through browser, gitolite has support for "syncing" configuration with gitweb. Or if you like cgit, which is a very good web frontend for git written in C, better, then you should look at this how-to.

当需要通过浏览器查看代码时，gitolite 支持与 gitweb 的“同步”配置。或者，如果您喜欢cgit，它是一个非常好的用 C 编写的 git 的 Web 前端，更好，那么您应该看看这个 how-to。

回答by James Moger

You might consider Gitblit, an open-source, integrated, pure Java Git server, viewer, and repository manager for small workgroups.

您可能会考虑Gitblit，这是一个开源的、集成的、纯 Java Git 服务器、查看器和小型工作组的存储库管理器。

回答by Mark Essel

Bare Bones Browser

裸骨浏览器

git instaweb --httpd=webrick

from the git scm book

来自git scm 书

combine it with something like the approach described herefor distributed development (credit to datagrokfor the well described concept)

将其与此处描述的分布式开发方法相结合（归功于datagrok的详细描述概念）

Launch a one-off git server from any local repository.

从任何本地存储库启动一次性 git 服务器。

I tweeted this alreadybut I thought it could use some expansion:

我已经发推文了，但我认为它可以使用一些扩展：

Enable decentralized git workflow: git config alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"

启用分散的 git 工作流： git config alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"

Say you use a git workflow that involves working with a core "official" repository that you pull and push your changes from and into. I'm sure many companies do this, as do many users of git hosting services like Github.

假设您使用 git 工作流程，该工作流程涉及使用核心“官方”存储库，您可以从中拉取和推送更改。我相信很多公司都会这样做，很多 git 托管服务（如 Github）的用户也是如此。

Say that server, or Github, goes down for a bit.

假设服务器或 Github 宕机了一段时间。

No worries, after all, one of the reasons you use git is so you have a copy of the entire project history in your local clone.

不用担心，毕竟，您使用 git 的原因之一是您在本地克隆中拥有整个项目历史的副本。

You can keep right on coding and committing, while you wait for the operations team to bring the server back to life. Note to self: buy doughnuts for operations team.

您可以继续编码和提交，同时等待运营团队让服务器恢复生机。自我注意：为运营团队购买甜甜圈。

But what if, during this downtime, you want to collaborate with another person, who may not be a git expert, on the same repository?

但是，如果在此停机期间，您想与另一个可能不是 git 专家的人在同一个存储库上进行协作，该怎么办？

Or, instead of downtime, what if you and your collaborator are in the field, and for some reason you can't get your VPN to let you connect to your official repo?

或者，如果您和您的合作者在现场，而不是停机时间，并且由于某种原因您无法让您的 VPN 连接到您的官方存储库，该怎么办？

Or, what if you and your collaborator are spiking out a bunch of experimental changes, and even though you have access, you don't want to push your unfinished mess into the official central repository? (Not even as feature branches.) Maybe you're in the middle of cleaning up a disastrous rebase or merge and the branches are all over the place.

或者，如果您和您的合作者提出了一系列实验性更改，并且即使您有访问权限，您也不希望将未完成的混乱推送到官方中央存储库中，该怎么办？（甚至不是功能分支。）也许您正在清理灾难性的变基或合并，并且分支到处都是。

Well, git, as you are probably aware, is a "distributed" version control system.

好吧，正如您可能知道的那样，git 是一个“分布式”版本控制系统。

Even though you might use a central "official" git repository in your workflow, you still have the ability to use git in a peer-to-peer manner, where you and your collaborator simply build and share commits with each other, and the central server never even has to know.

即使您可能在工作流程中使用中央“官方” git 存储库，您仍然可以以点对点的方式使用 git，您和您的合作者只需在其中构建和共享彼此的提交，以及中央服务器甚至不必知道。

So, how do you get your branches and commits over to them, or vice versa?

那么，你如何获得你的分支并提交给它们，反之亦然？

• You could use git's facilities for e-mailing patches. But that's a bit inelegant and requires some knowledge on their end of how to apply e-mailed patches.
• You could create an account on your own machine for your collaborator to ssh into. But maybe you don't have local root access, or maybe you don't trust them with SSH access to your box.
• You could clone your repo onto a thumbdrive and pass it back and forth. But that's rather tedious, especially if you happen to be on the same local network, and requires a thumb drive.

• 您可以使用 git 的工具通过电子邮件发送补丁。但这有点不雅，需要他们了解如何应用电子邮件补丁。
• 您可以在自己的机器上创建一个帐户，供您的合作者通过 ssh 进入。但也许您没有本地 root 访问权限，或者您不信任他们通过 SSH 访问您的设备。
• 您可以将您的存储库克隆到拇指驱动器上并来回传递。但这相当乏味，特别是如果您碰巧在同一个本地网络上，并且需要拇指驱动器。

You can probably think of other methods, too. But there's a super easy way: if you can see each other on the network, you can launch a one-off git server that they can use as their remote to clone, fetch, and pull your changes, and kill it when you're done with it.

您可能也可以想到其他方法。但是有一个超级简单的方法：如果你能在网络上看到对方，你可以启动一个一次性的 git 服务器，他们可以用它作为远程克隆、获取和拉取你的更改，并在你离开时终止它完成它。

The tool that enables this is git daemon, which has a lot of options and functionality, but for the purpose of enabling this easy one-off "just serve up the repo I'm in," the way to use it is to create an alias. I like to call it git serve. Run:

启用此功能的工具是git daemon，它具有许多选项和功能，但为了实现这种简单的一次性“只需提供我所在的存储库”，使用它的方法是创建别名。我喜欢这样称呼它git serve。跑：

git config --global alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"

Using an alias is actually crucial, because git aliases are executed in the base directory of your working tree. So the path '.git' will always point to the right place, no matter where you are within the directory tree of your repository.

使用别名实际上很重要，因为 git 别名是在工作树的基本目录中执行的。因此，无论您在存储库目录树中的哪个位置，路径“.git”都将始终指向正确的位置。

Use your new git servelike so:

git serve像这样使用你的新：

1. Run git serve. "Ready to rumble," it will report. Git is bad-ass.
2. Find out your IP address. Say it's 192.168.1.123.
3. Say "hey Jane, I'm not ready/able to push these commits up to origin, but you can fetch my commits into your clone by running git fetch git://192.168.1.123/"
4. Press ctrl+c when you don't want to serve that repo any longer.

1. 运行git serve。“准备隆隆声，”它会报告。Git是个坏蛋。
2. 找出您的 IP 地址。假设它是 192.168.1.123。
3. 说“嘿，Jane，我还没有准备好/无法将这些提交推送到原点，但是您可以通过运行将我的提交获取到您的克隆中git fetch git://192.168.1.123/”
4. 当您不想再提供该存储库时，请按 ctrl+c。

You could also tell Jane to git clone git://192.168.1.123/ local-repo-nameif she does not yet have a clone of the repository. Or, use git pull git://192.168.1.123/ branchnameto do a fetch and merge at once, useful if you are working together on a feature branch.

如果 Janegit clone git://192.168.1.123/ local-repo-name还没有存储库的克隆，您也可以告诉她。或者，用于git pull git://192.168.1.123/ branchname一次获取和合并，如果您在功能分支上一起工作，则很有用。

Note however that you shouldn't do this on hostile networks if you keep secrets in your repository, because there's no authentication. It doesn't advertise its existence, but anybody with a a port scanner can find it, connect to it, and clone your repo.

但是请注意，如果您在存储库中保留机密，则不应在敌对网络上执行此操作，因为没有身份验证。它不会宣传它的存在，但任何拥有端口扫描器的人都可以找到它、连接到它并克隆你的存储库。

But it's not super dangerous because it is read-only by default. Read the git daemonman page carefully if you think that you want to enable write access. In the case where you want to obtain your collaborator's commits, it's much safer to leave it read-only, and ask your collaborator to also run this command, so you can pull from them.

但这并不是非常危险，因为它默认是只读的。git daemon如果您认为要启用写访问，请仔细阅读手册页。如果您想获取合作者的提交，将其保留为只读更安全，并要求您的合作者也运行此命令，以便您可以从中提取。

Tangentially related: on the subject of one-off servers, if you want to temporarily share a bunch of static files over HTTP: python -m SimpleHTTPServer

切线相关：关于一次性服务器的主题，如果您想通过 HTTP 临时共享一堆静态文件： python -m SimpleHTTPServer

回答by corysus

If you need good, easy GIT server than you must try GitBlit. Also i use gitolite but it only server, with GitBlit you get all in one, server, admin, repos. manager ... URL: http://gitblit.com/

如果你需要好的、简单的 GIT 服务器，那么你必须尝试 GitBlit。我也使用 gitolite，但它只是服务器，使用 GitBlit，您可以将服务器、管理员、存储库合二为一。经理...网址：http: //gitblit.com/

回答by Sebastian

https://rhodecode.comis an open source web app for Git & Mercurial which can be very easily installed under any operating system (an installer is included).

https://rhodecode.com是一个用于 Git 和 Mercurial 的开源 Web 应用程序，可以非常轻松地安装在任何操作系统下（包括安装程序）。

RhodeCode (the new version is called RhodeCode Enterprise) adds missing Git features like code review and it is generally speaking very fast and reliable.

RhodeCode（新版本称为 RhodeCode Enterprise）添加了缺少的 Git 功能，例如代码，并且总体来说非常快速和可靠。

回答by simptheitroad

It may notbe the most commongit server setup, but having played with different layouts, tools, mirroring and permission schemes, I'd say one pretty solid alternative for enterprise repositories is Gerrit, which may seem surprising as it is more known as a code review tool. We started using it as code review and it slowly became our main repository, deprecating g3/gitolite

它可能不是最常见的git 服务器设置，但是使用了不同的布局、工具、镜像和权限方案，我认为企业存储库的一个非常可靠的替代方案是Gerrit，这似乎令人惊讶，因为它更被称为代码工具。我们开始使用它作为代码，它慢慢成为我们的主要存储库，弃用 g3/gitolite

• It is straightforward to deploy (you basically drop the .war in a tomcat)
• has a web ui to manage repositories, groups and permissions (or a ssh cli)
• has a built-in java ssh and git implementation, so you have nothing else to set up
• ldap support for users and groups (usually a must for companies)
• a very flexible permission system (with project groups, permission inheritance, restricting read/write/branching/unreviewed writes/etc)
• code review capabilities (if you're into that thing)
• repo mirroring (to push some repositories to github or other public repo)

• 部署很简单（您基本上将 .war 放在 tomcat 中）
• 有一个 web ui 来管理存储库、组和权限（或 ssh cli）
• 具有内置的 java ssh 和 git 实现，因此您无需进行其他设置
• 对用户和组的 ldap 支持（通常是公司必须的）
• 一个非常灵活的权限系统（有项目组，权限继承，限制读/写/分支/未审核写/等）
• 代码能力（如果你喜欢那件事）
• 存储库镜像（将一些存储库推送到 github 或其他公共存储库）

In addition, it's used by large projects (e.g. android, chrome) so it does scales and is now fairly solid. Just give your users the PUSH permission if you want to allow bypassing the code review part.

此外，它被大型项目（例如 android、chrome）使用，因此它可以扩展并且现在相当可靠。如果您想允许绕过代码部分，只需给您的用户 PUSH 权限。

回答by Christian Specht

You can even install GitHub on your local server (but not for free):

您甚至可以在本地服务器上安装 GitHub（但不是免费的）：

https://enterprise.github.com/

https://enterprise.github.com/