Como configurar um servidor Git privado

Se você deseja configurar o controle de origem para um projeto, mas prefere não hospedá-lo em um serviço como o GitHub, você pode executar seu próprio servidor git em um VPS para armazenar seu código e atuar como um repositório mestre para qualquer colaborador .

Por que executar seu próprio servidor?

Com quantos provedores git hospedados gratuitamente existem, como GitHub, GitLab e Bitbucket, não faz muito sentido fazer você mesmo. Mas, existem algumas situações em que é uma solução viável.

Primeiro, executar seu próprio servidor é muito mais privado, especialmente se você estiver trabalhando em um código que prefere não armazenar na nuvem de outra pessoa. ” Isso não quer dizer que provedores como o GitLab não são seguros, mas hospedar tudo sozinho pode dar a algumas pessoas mais paz de espírito.

Além disso, se você estiver usando um serviço de terceiros, há restrições no tamanho do arquivo que podem não ser ideais. O GitHub não permite arquivos com mais de 100 MB, o que pode ser um grande problema para projetos com grandes arquivos binários. Usar seu próprio servidor remove esse limite, supondo que você possa pagar por mais espaço no disco rígido.

Seja qual for o seu caso de uso, você provavelmente pode fazer melhor do que o git barebones. GitLab &’ s Community Edition é gratuito e de código aberto, e é fácil de configurar em seu próprio servidor. Isso oferece a você todos os benefícios de hospedar você mesmo, juntamente com uma interface da web muito agradável e várias ferramentas de CI / CD. Recomendamos enfaticamente que você use o GitLab se tiver espaço livre no servidor. (Ele requer cerca de 3 GB de RAM.) Você pode ler nosso guia de instalação e configuração para saber mais.

Mas, se você não quiser todos os recursos e apenas executar um controle remoto git simples, pode continuar lendo.

Os controles remotos do Git são apenas o repositório de outra pessoa

A primeira coisa a observar sobre o git é que hospedar um servidor não é realmente muito complicado. Git usa um modelo de controle de origem distribuído; seu clone local de um repositório não se conecta a todos os seus colegas de trabalho, mas se conecta a um “ remoto ” geralmente em um servidor ou serviço central externo. Ao pressionar e puxar, você faz modificações na cópia mestre oficial do remoto. Quando seus colegas de trabalho buscam remotamente, eles baixam seus commits.

Você pode executar git tecnicamente como um serviço completamente descentralizado. Se você tivesse duas pessoas, cada uma obteria atualizações uma da outra. (Enviar para repositórios que não são do servidor não é aconselhável nesta configuração.) Não é realmente utilizável na prática, a menos que ambas as partes tenham endereços IP estáticos e estejam sempre online, então a maioria das pessoas opta pelo cliente-servidor modelo.

Então, tudo o que um servidor git é, então, é apenas um repositório regular que é configurado como a cópia master e aberto para a internet. É surpreendentemente simples de configurar. Primeiro, precisamos criar um novo usuário. Git usa SSH para autenticação e todo o tráfego entre servidores e clientes, portanto, precisaremos de um usuário de serviço para gerenciar o repo.

 sudo useradd git 

A seguir, mude para o usuário git para o resto da configuração:

 su git 

Você precisará adicionar suas chaves SSH ao arquivo authorized_keys do usuário git:

 nano ~ / . ssh / authorized_keys 

Esta é uma área onde serviços como GitHub e GitLab têm batida Git de linha de comando. O gerenciamento de acesso não é facilmente tratado dessa forma, pois você precisará fornecer a todos acesso ao mesmo usuário do serviço, o que não é o ideal, ou precisará configurar usuários separados para cada pessoa, o que também não é ideal. De qualquer forma, os commits aparecerão com qualquer nome de usuário e e-mail que o usuário final tiver definido nas configurações do git.

De qualquer forma, para criar o repositório real, simplesmente execute git init no diretório inicial do usuário git:

 git init --bare repository. git 

A opção --bare é necessária aqui. Normalmente, quando você clonar novamente um repositório, o git armazena todos os arquivos que usa para gerenciar versões na pasta . git oculta e mantém uma versão utilizável de onde quer que esteja o seu HEAD retirado. Isso geralmente torna sua pasta repo cerca de duas vezes maior do que seria sem o git, embora possa ser maior se você tiver arquivos binários grandes e muitas mudanças ao longo do tempo.

Um repositório vazio é simplesmente um repo sem as versões utilizáveis ​​dos arquivos atualmente retirados. Em vez disso, a pasta do repositório é apenas o conteúdo do que seria a pasta . git. Isso economiza espaço de armazenamento e configura o repositório como um servidor mestre. Como não há conteúdo local, não haverá conflitos com o branch HEAD. É uma convenção nomear repositórios vazios com a extensão de arquivo . git, mas não é explicitamente necessário.

Isso é tudo o que é necessário no lado do servidor. Em sua máquina local, você &’ precisará clonar o repo ou adicionar um novo controle remoto:

 git remote add origin git@example. com: repository. git 

O URL começa com git @ porque está se conectando por SSH como o usuário git. O: repository. git no final é na verdade um nome de caminho, não apenas um identificador. O caminho é relativo ao diretório inicial do usuário git, então se você colocou o repositório em outro lugar, você vai querer movê-lo aqui ou usar o nome do caminho completo.

Depois de conectar seu repositório local, você deverá ter acesso total para enviar e receber normalmente. Lembre-se de que o git padrão não possui um sistema de permissões integrado, portanto, não há nada que impeça qualquer pessoa com acesso ao usuário git de ter controle total sobre seu repositório principal.

Via: How to Geek