Servidor Git Como o GitHub? [fechadas]

412

Eu sou um usuário antigo do Subversion que tentará o Git. Eu li um pouco sobre isso e entendi a natureza distribuída - vejo muitos benefícios.

No entanto, gosto da ideia de um servidor central que possa assumir o papel de backups, sistema de registro, etc., enquanto ainda estiver usando o Git para minha ramificação e compartilhamento local. Como não estou desenvolvendo um projeto de código aberto, não posso usar o Github (sem pagar). Portanto, minha pergunta é: qual é a melhor maneira de executar um servidor git local?

Sei que isso pode ser contra o padrão de uso padrão do Git, mas será útil para o meu projeto. Quaisquer preocupações que eu possa ter esquecido são sempre bem-vindas, no entanto.

Obrigado!

git 
— skaz
fonte
50
O uso de um servidor centralizado como você descreve é, na verdade, um padrão de uso padrão para sistemas de controle de versão distribuídos; portanto, não se preocupe. :-)
— Aasmund Eldhuset 31/03
8
Ahh - pensei que era mais a exceção. Queria se defender "se você tem centralização, simplesmente não entende!" comentários. Obrigado.
— skaz
27
Um pensamento razoável. :-) No meu entendimento, o grande ponto dos VCS distribuídos não é que você não deve ter um repositório central (isso é geralmente muito útil), mas sim que não é obrigado a usar o repositório central - você pode executar confirmações locais, e é fácil trocar revisões com pessoas específicas, se necessário, e você pode até ter vários repositórios "centrais" (no git, qualquer outro repositório, independentemente da função que ele tenha, é chamado de remoto , e você pode adicione quantas você quiser). E os DVCS geralmente têm modelos de ramificação muito flexíveis (o git brilha aqui).
— Aasmund Eldhuset 31/03
15
Para resumir / reformular o comentário de Aasmund: o objetivo de um DVCS geralmente não é eliminar o repositório centralizado, mas fornecer a todos os outros usuários todo o poder do VCS.
— Cascabel 31/03
2
O Google tem um novo repositório de fontes de nuvem que permite repositórios particulares: cloud.google.com/tools/cloud-repositories Além disso, FWIW, não sabe por que isso está marcado como fora de tópico!
— Josh M.

Respostas:

203

Você pode simplesmente configurar um servidor ssh e executar um repositório central lá. Todos os desenvolvedores simplesmente concordam (por uma questão de política) em enviar para o servidor quando terminarem de fazer confirmações. Esse é o padrão de uso no meu local de trabalho. Muito CVS e SVN-like.

  1. Encontre um lugar para colocar o repositório ( /var/gitrootpor exemplo).
  2. Crie um novo repositório ( mkdir project.git && cd project.git && git init --bare --shared=group).
  3. Em seguida, no seu cliente, clone o repositório remoto ( git clone ssh://yourserver.com/var/gitroot/project.git && cd project)
  4. adicione alguns arquivos ( git add README)
  5. commit ( git commit -m "Initial import"),
  6. push ( git push origin master)

Isso deve configurar as coisas para você.

— Chris Eberle
fonte
5
Só para esclarecer: Instale o git em outro servidor (acessível) e crie um repositório. Faça com que os clientes clonem esse repositório. Quando um cliente concluir uma correção, envie para o repositório do servidor. Obrigado!
— skaz
8
+1. De fato, esse é o padrão de uso para uso colaborativo do git.
— Aasmund Eldhuset 11/12/12
1
Este erro ocorreu ao enviar o mestre de origem :::: Contando objetos: 3, concluídos. Escrevendo objetos: 100% (3/3), 244 bytes | 0 bytes / s, concluído. Total 3 (delta 0), reutilizado 0 (delta 0) remoto: erro: permissão insuficiente para adicionar um objeto ao banco de dados do repositório ./objetos remoto: fatal: falha ao gravar o erro do objeto: falha ao descompactar: ​​saída anormal dos objetos descompactados Para ssh: //localhost/var/gitroot/project.git! [remoto rejeitado] erro master -> master (erro de descompactação): falha ao enviar algumas refs para 'ssh: //localhost/var/gitroot/project.git'
— Abdo
3
Eu escrevi um post sobre como configurar um repositório Git local há algum tempo. São 10 minutos no máximo. A coisa mais difícil é definir estratégias adequadas de backup de servidor local, administrar o servidor, etc.
— atmosx
Você não pode simplesmente correr git init --bare project.git?
— Dan Dascalescu 26/01
199

Gitorious é uma interface da web de código aberto para o git que você pode executar em seu próprio servidor, assim como o github:

http://getgitorious.com/

Atualizar:

http://gitlab.org/ também é outra alternativa agora.

Atualização 2:

Gitorious agora se juntou ao GitLab

— Craig
fonte
5
Parece bom, mas a configuração parece pesada (especialmente para um usuário não-rails) [ cjohansen.no/en/ruby/setting_up_gitorious_on_your_own_server ]
— gatoatigrado
1
O processo de instalação está sendo simplificado e tornado menos "Rails-y". Há também um instalador automatizado para servidores CentOS (e um dispositivo pré-construído) disponível na página Instalar Gitorious em getgitorious.com.
— Thomanil
3
Parece que o Gitorious não é mais uma solução de hospedagem privada gratuita de código aberto.
— Mingming
1
Se você acessar o getgitorious.com e clicar em Instalador no Gitorious Community Edition, isso não lhe dará uma solução gratuita de hospedagem privada de código aberto?
— Craig
16
Também o gitlab.org é outra alternativa desenvolvida desde a minha resposta.
— Craig
74

Experimente o GitLab

A melhor ferramenta GUI do git que eu já usei. É muito semelhante ao GitHub.

É de código aberto (licença MIT) e é o software de gerenciamento git mais instalado, com mais de 25.000 instalações. Possui lançamentos mensais e uma comunidade ativa com mais de 375 colaboradores. Você pode ter repositórios privados, internos e públicos ilimitados em seu próprio servidor. É um aplicativo Ruby on Rails que roda na maioria das plataformas Unix.

— Plamen Nikolov
fonte
1
Eu concordo, é incrível. (+1) Mas, neste comentário, é difícil instalar. Seria ótimo se eles pudessem empacotar rpm, deb etc.
— Synesso
2
Eu achei a relativamente nova configuração de script único para o Ubuntu bastante simples. Mesmo sem ele, é principalmente uma questão de seguir as instruções do site. Eu nunca usei rails ou realmente mesmo servidor Ubuntu e o executei na primeira tentativa.
— Jon Shier
Ocorreu um problema ao integrá-lo ao Active Directory via LDAP.
— riezebosch
2
Atualmente, o GitLab é muito fácil de instalar. É apenas uma questão de descompactar um pacote. Consulte about.gitlab.com/downloads
— Job
2
O Gitlab Enterprise não é gratuito, é claro, mas existe a edição comunitária , que é gratuita e também fácil de instalar. Embora exija cerca de 800 MB de espaço em disco, pois instala alguns mecanismos de banco de dados e muitas dependências.
— precisa saber é o seguinte
39

Se você não se importa com a linha de comando, o gitolite é um deleite absoluto ao trabalhar em um ambiente corporativo em que você precisa definir direitos de acesso diferentes em repositórios diferentes. É uma espécie de versão mais recente da gitosis mencionada pelo @Chris.

Aqui está o resumo do site do autor:

O Gitolite permite que você use um único usuário em um servidor para hospedar muitos repositórios git e fornecer acesso a muitos desenvolvedores, sem precisar fornecer a eles IDs de usuário reais ou acesso shell ao servidor. A mágica essencial para fazer isso é o acesso ao pubkey do ssh e o arquivo allowed_keys, e a inspiração foi um programa mais antigo chamado gitosis.

O Gitolite pode restringir quem pode ler (clonar / buscar) ou gravar em (enviar) um repositório. Também pode restringir quem pode enviar para qual filial ou tag, o que é muito importante em um ambiente corporativo. O Gitolite pode ser instalado sem a necessidade de permissões de root e sem nenhum software adicional além do próprio git e perl.

Ele tem um conjunto de recursos bastante abrangente, mas uma coisa de que gosto muito é que a edição do dia-a-dia é feita através de um repositório git especial. Ou seja, adicionar um usuário é apenas

  • Adicionar usuário ao arquivo de configuração
  • Adicione a chave ssh do usuário
  • Confirme a mudança
  • Empurre-o para gitólito
  • Voila, a configuração está ativa!

E ao precisar examinar o código pelo navegador, o gitolite oferece suporte para a "sincronização" da configuração com o gitweb. Ou, se você gosta do cgit , que é um frontend muito bom da web para o git, escrito em C, melhor, então veja este tutorial .

— stigkj
fonte
24

Você pode considerar o Gitblit , um servidor Java Git de código aberto, integrado e puro, visualizador e gerenciador de repositório para pequenos grupos de trabalho.

— James Moger
fonte
Gitblit parece perfeito para a minha candidatura, mas me preocupa que o último lançamento foi em 2016.
— Roberto
1
@Roberto, um ponto válido. Acho que depende do que você precisa ou do que é importante para você. Se funcionar para você como está, ainda poderá ser uma opção válida. Se você estiver preocupado com correções oportunas de bugs ou precisar de mais recursos, talvez não.
— Florian
15

Navegador Bare Bones

git instaweb --httpd=webrick

do livro git scm

combine-o com algo como a abordagem descrita aqui para desenvolvimento distribuído (crédito ao datagrok pelo conceito bem descrito)

Inicie um servidor git único a partir de qualquer repositório local.

Eu twittou isso já, mas achei que poderia usar alguma expansão:

Ative o fluxo de trabalho descentralizado do git: git config alias.serve "daemon --verbose --export-all --base-path = .git --reuseaddr --strict-caminhos .git /"

Digamos que você use um fluxo de trabalho git que envolva o trabalho com um repositório "oficial" principal, no qual você puxa e envia suas alterações de e para dentro. Tenho certeza que muitas empresas fazem isso, assim como muitos usuários de serviços de hospedagem git como o Github.

Digamos que o servidor, ou Github, fique um pouco inativo.

Afinal, não se preocupe, uma das razões pelas quais você usa o git é para ter uma cópia de todo o histórico do projeto no seu clone local.

Você pode continuar a codificar e confirmar, enquanto aguarda a equipe de operações trazer o servidor de volta à vida. Nota para si mesmo: compre rosquinhas para a equipe de operações.

Mas e se, durante esse tempo de inatividade, você quiser colaborar com outra pessoa, que pode não ser especialista em git, no mesmo repositório?

Ou, em vez de tempo de inatividade, e se você e seu colaborador estiverem em campo e, por algum motivo, você não conseguir que sua VPN permita a conexão com seu repo oficial?

Ou então, se você e seu colaborador estão lançando várias mudanças experimentais e, mesmo tendo acesso, não deseja colocar sua bagunça inacabada no repositório central oficial? (Nem mesmo como ramificações de recursos.) Talvez você esteja no meio de uma recuperação ou mesclagem desastrosa e as ramificações estão por toda parte.

Bem, o git, como você provavelmente sabe, é um sistema de controle de versão "distribuído" .

Mesmo que você possa usar um repositório git "oficial" central em seu fluxo de trabalho, ainda poderá usar o git de maneira ponto a ponto, onde você e seu colaborador simplesmente criam e compartilham confirmações entre si e com a central servidor nunca precisa saber.

Então, como você consegue seus ramos e se compromete com eles, ou vice-versa?

  • Você pode usar as instalações do git para enviar correções por e-mail. Mas isso é um pouco deselegante e requer algum conhecimento sobre como aplicar patches enviados por email.
  • Você pode criar uma conta em sua própria máquina para a qual seu colaborador se hospede. Mas talvez você não tenha acesso root local ou talvez não confie neles com acesso SSH à sua caixa.
  • Você pode clonar seu repositório em um pendrive e passá-lo para frente e para trás. Mas isso é bastante entediante, especialmente se você estiver na mesma rede local e exigir um pen drive.

Você provavelmente pode pensar em outros métodos também. Mas há uma maneira super fácil: se você pode se ver na rede, poderá iniciar um servidor git único que ele possa usar como controle remoto para clonar, buscar e puxar suas alterações e matá-lo quando estiver feito com isso.

A ferramenta que permite isso é git daemon, que tem muitas opções e funcionalidades, mas com o objetivo de permitir esse processo "fácil de servir o repo em que estou", a maneira de usá-lo é criar um alias. Eu gosto de chamar git serve. Corre:

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

Usar um alias é realmente crucial, porque os aliases do git são executados no diretório base da sua árvore de trabalho. Portanto, o caminho '.git' sempre apontará para o lugar certo, não importa onde você esteja na árvore de diretórios do seu repositório.

Use o seu novo git serveassim:

  1. Corra git serve. "Pronto para fazer barulho", relatará. Git é malvado.
  2. Descubra o seu endereço IP. Digamos que seja 192.168.1.123.
  3. Diga "ei, Jane, eu não estou pronto / apto a enviar esses commits até a origem, mas você pode buscar meus commits no seu clone executando git fetch git://192.168.1.123/"
  4. Pressione ctrl + c quando não desejar mais veicular esse repositório.

Você também pode dizer a Jane git clone git://192.168.1.123/ local-repo-namese ela ainda não possui um clone do repositório. Ou use git pull git://192.168.1.123/ branchnameuma busca e mesclagem de uma só vez, útil se você estiver trabalhando juntos em uma ramificação de recurso.

Observe, no entanto, que você não deve fazer isso em redes hostis se guardar segredos em seu repositório, porque não há autenticação. Ele não anuncia sua existência, mas qualquer pessoa com um scanner de porta pode encontrá-lo, conectar-se a ele e clonar seu repositório.

Mas não é super perigoso, porque é somente leitura por padrão. Leia a git daemonpágina de manual com atenção se achar que deseja ativar o acesso de gravação. No caso em que você deseja obter as confirmações do seu colaborador, é muito mais seguro deixá-lo como somente leitura e peça ao seu colaborador para também executar este comando, para que você possa retirá-las.

Relacionado tangencialmente: no assunto de servidores únicos, se você deseja compartilhar temporariamente um monte de arquivos estáticos por HTTP: python -m SimpleHTTPServer

— Mark Essel
fonte
11

Se você precisa de um servidor GIT fácil e bom, tente o GitBlit. Também uso gitolite, mas é apenas um servidor, com o GitBlit você obtém tudo em um, servidor, administrador, repositórios. gerente ... URL: http://gitblit.com/

— corysus
fonte
9

https://rhodecode.com é um aplicativo da web de código aberto para o Git & Mercurial, que pode ser facilmente instalado em qualquer sistema operacional (um instalador está incluído).

O RhodeCode (a nova versão é chamada RhodeCode Enterprise) adiciona recursos ausentes do Git, como revisão de código e, geralmente, é muito rápido e confiável.

— Sebastian
fonte
1
Na verdade, eu executo minha própria instância aqui: code.gmgauthier.com . A versão 3.x é notavelmente limpa e estável. Eu o uso para muito mais do que código, na verdade (embora haja muito disso por aí). Eu o uso para manter cópias principais de meus diários pessoais, manuscritos para dois livros, scripts de podcast e rascunhos de blog. É ideal para isso, em parte porque renderiza Markdown e RestructuredText para você, tornando os rascunhos muito legíveis de qualquer lugar.
— Greg Gauthier
8

Você também pode instalar o Indefero , é um clone GPL do GoogleCode, pois suporta o Subversion e o Git, você pode ter uma transição suave. Eu sou o autor de Indefero.

— Loïc d'Anterroches
fonte
Estou usando e gosto. Mas o design está um pouco desatualizado. Ainda é mantido?
— Jaroslav
8

Pode não ser a configuração mais comum do servidor git, mas, tendo jogado com diferentes layouts, ferramentas, esquemas de espelhamento e permissão, eu diria que uma alternativa bastante sólida para repositórios corporativos é o Gerrit , que pode parecer surpreendente, pois é mais conhecido como um ferramenta de revisão de código. Começamos a usá-lo como revisão de código e lentamente se tornou nosso repositório principal, descontinuando o g3 / gitolite

  • É simples de implantar (você basicamente solta o .war em um tomcat)
  • possui uma interface web para gerenciar repositórios, grupos e permissões (ou um ssh cli)
  • possui uma implementação java ssh e git, para que você não tenha mais nada para configurar
  • Suporte LDAP para usuários e grupos (geralmente obrigatório para empresas)
  • um sistema de permissão muito flexível (com grupos de projetos, herança de permissão, restrição de leitura / gravação / ramificação / gravações não revisadas / etc)
  • recursos de revisão de código (se você gosta disso)
  • repo mirroring (para empurrar alguns repositórios para o github ou outro repo público)

Além disso, é usado por grandes projetos (por exemplo, android, chrome), por isso dimensiona e agora é bastante sólido. Apenas dê a seus usuários a permissão PUSH se você deseja permitir ignorar a parte da revisão de código.

— simpoir
fonte
7

Para uma hospedagem remota Como outros usuários disseram que o bitbucket.org oferece repositórios particulares gratuitos, eu o uso sem problemas.

Para redes locais ou LAN , adicionarei este scm-manager.org (um único arquivo executável, é realmente simples de instalar, é feito em Java para que possa ser executado no Linux ou Windows). Caso você o instale, essas são as senhas padrão.

Username: scmadmin
Password: scmadmin
— Hernán Eche
fonte
3
obrigado por fornecer as credenciais padrão.
— Ryan Williams
6

Enquanto isso, o site de hospedagem Mercurial Bitbucket começou a oferecer repositórios Git também.

Portanto, se você não precisa de um servidor local , apenas um local central onde você pode hospedar repositórios particulares do Git gratuitamente, o IMO Bitbucket é a melhor escolha.

De graça, você obtém repositórios Git e Mercurial privados e públicos ilimitados.
A única limitação é que, no plano gratuito, não mais que cinco usuários podem acessar seus repositórios privados (para mais, você precisa pagar).
Veja https://bitbucket.org/plans para mais informações!

— Christian Specht
fonte
2

Se você quer apenas seu repositório em um local central, isso é bastante fácil com o controle de versão distribuído como o Git:
Você pode simplesmente colocar seu repositório central em alguma pasta compartilhada em uma máquina central e todos podem cloná-lo a partir daí.

Se você deseja um site "real" em seu servidor local, conheço o site de hospedagem Git http://repo.or.cz .
Parece ter menos recursos que o GitHub, mas, diferentemente do GitHub, você pode obter o código-fonte e hospedá-lo em seu próprio servidor local.

Isenção de responsabilidade: só li sobre repo.or.cz, nunca tentei sozinho!

— Christian Specht
fonte
2

para configurações simples, você pode fornecer acesso ssh a um servidor central e configurar o diretório de trabalho de cada usuário para enviar / receber a partir dessa 'origem'. Essa seria a configuração mais simples e comum para equipes pequenas.

Você também pode procurar por gitosis, que oferece um servidor http e a capacidade de gerenciá-lo remotamente. Dessa forma, você não precisa conceder acesso ssh e tudo o que isso implica para cada comunicador.

— raio
fonte
2

Para adicionar o que Chris disse, você pode usar gitosis (http://eagain.net/gitweb/?p=gitosis.git) para controlar quem pode realmente acessar o repositório.

Dependendo do seu uso, você também pode usar hooks (na pasta .git / hooks) para que o seu código seja automaticamente inserido no sistema de arquivos do servidor quando você enviar da máquina local. Aqui está um script popular para fazer isso: http://utsl.gen.nz/git/post-update . Isso não será necessário em todos os casos.

— liamacheung
fonte
O link para o script de pós-atualização está morto ...
— Morten Jensen
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.