Git pode usar os quatro principais protocolos de transferência de dados: Local, HTTP, Secure Shell (SSH) e Git. Aqui nós discutiremos o que eles são e em que circunstâncias você poderia querer (ou não) usá-los.
O mais básico é o Protocolo Local, em que o repositório remoto é outro diretório no disco. Isso é frequentemente usado se todo seu time tem acesso à um sistema de arquivos compartilhado como uma montagem NFS, ou menos provavelmente no caso em que todos acessem o mesmo computador. O último não seria o ideal, porque todas as intâncias do seu repositório de código ficariam no mesmo computador, fazendo com que uma perda catastrófica seja muito mais provável.
Se você tem um sistema de arquivos montado e compartilhado, então você pode clonar, enviar e baixar do repositório local. Para clonar um repositório como esse ou adicionar um como remoto em um projeto existente, use o caminho para o repositório como uma URL.
Por exemplo, para clonar um repositório local, você pode executar algo assim:
$ git clone /srv/git/project.gitOu você pode fazer assim:
$ git clone file:///srv/git/project.gitGit funciona um pouco diferente se você explicitamente especificar file:// no começo da URL.
Se você apenas especificar o caminho, o Git tenta usar caminhos absolutos ou diretamente copiar os arquivos que ele precisa.
Se você especificar file://, o Git dispara um processo que ele normalmente usa para transferir dados pela rede que normalmente é um método de transferência de dados muito menos eficiente.
O principal motivo para especificar o prefixo file:// é se você quer uma cópia limpa do repositório com referências estranhar ou objetos deixados de fora – geralmente depois de importar de outro sistema de controle de versão or algo similar (veja ch10-git-internals.asc para tarefas de manutenção).
Nós vamos usar o caminho normal porque fazendo isso é quase sempre mais rápido.
Para adicionar um repositório local em um projeto Git já existente, você pode executar algo assim:
$ git remote add local_proj /srv/git/project.gitEntão, você pode enviar e baixar desse repositório como se você estivesse fazendo pela rede.
Os prós dos repositórios baseados em arquivos são que eles são simples e usam permissões de arquivo e acessos de rede já existentes. Se você já tem um sistema de arquivos compartilhado que seu time inteiro tem acesso, configurar um repositório é muito fácil. Você cola a cópia do repositório vazio (bare repository) em algum lugar que todos tem acesso para ler/escrever permissões como você faria com qualquer outro diretório.
Nós discutiremos como exportar uma cópia de um repositório vazio (bare repository) para esse propósito em [r_git_on_the_server].
Esta é uma boa opção para rapidamente pegar o trabalho do repositório de trabalho de outra pessoa.
Se você ou seu colega de trabalho estão trabalhando no mesmo projeto e ele quiser que você verifique alguma coisa, executar um comando como git pull /home/john/project geralmente é mais fácil que enviar para um servidor remoto e baixar.
Os contras desse método são que geralmente acesso compartilhado é mais difícil de configurar e acessar de múltiplos locais do que acessos básicos à rede. Se você quer enviar do seu notebook quando você estiver em casa , você tem que montar uma unidade remota, que pode pode ser mais difícil e lenta comparado ao acesso baseado em rede.
É importante mencionar que essa não é necessariamente a opção mais rápida se você está usando montagens compartilhadas de alguma forma. Um repositório local é mais rápido apenas se você tiver acesso aos dados. Um repositório NFS geralmente é mais lento que um repositório em SSH no mesmo servidor, permitindo que o Git execute discos locais em cada sisteme.
Finalmente, este protocolo não prote o repositório contra danos acidentais. Todo usuário tem acesso total no diretório "remoto" pelo shell, e isso não os previne de mudar ou remover arquivos internos do Git e corromper o repositório.
Git pode se comunicar por HTTP em dois jeitos diferentes.
Antes do Git 1.6.6 havia apenas uma maneira de fazer isso, que era muito simples e geralmente somente leitura. Na versão 1.6.6 foi introduzido um protocolo novo e mais inteligente, que tornava o Git capaz de inteligentemente negociar a transferência de dados de modo similar ao que faz por SSH. Nos últimos anos, esse novo protocolo HTTP se tornou muito popular por ser mais simples para o usuário e mais inteligente na forma como se comunica. A versão mais recente é gerealmente referida como protocolo HTTP "Smart" e a anterior como HTTP "Dumb". Nós cobriremos o mais novo protocolo HTTP "Smart" primeiro.
O protocolo HTTP "Smart" funciona muito semelhantemente ao protocolo SSH ou Git, mas funciona no padrão das portas HTTP/S e pode usar vários mecanismos de autenticação HTTP, isso significa que geralmente é mais fácil para o usuário do que outros, como SSH, já que você pode usar coisas como usuário e senha para autenticação ao invés de ter que configurar chaves SSH.
Ele se tornou provavelmente o jeito mais popular de usar o Git agora, já que pode ser configurado para servir aninomamente como protocolo git://, e também pode ser enviado com autenticação e criptografia como o protocolo SSH.
Ao invés de ter que configurar diferentes URLs para essas coisas, você pode usar uma única URL para ambos.
Se você tentar enviar e o repositório requerer autenticação (o que ele normalmente deveria fazer), o servidor pode pedir usuário e senha.
O mesmo vale para acessos de leitura.
De fato, para serviços como GitHub, a URL que você vê o repositório online (por exemplo, "https://github.com/schacon/simplegit") é a mesma URL que você usa para clonar e, se você tiver acesso, enviar.
Se o servidor não responder com serviço Git HTTP Smart, o cliente Git vai tentar voltar para o protocolo mais simples, o HTTP "Dumb". O protocolo Dumb espera que o repositório vazio (bare repository) do Git sirva os arquivos como um servidor web normal. A beleza do protocolo HTTP Dumb é sua simplicidade de configuração. Basicamente, tudo que você tem que fazer é colocar o repositório vazio (bare repository) sob o documento raiz do seu HTTP e configurar um hook post-update específico, e você está pronto (Veja ch08-customizing-git.asc). Nesse ponto, qualquer um que possa acessar o servidor web no qual você colocou o repositório também pode cloná-lo. Para acessos de leitura para seu repositório por HTTP, faça algo como:
$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-updateIsso é tudo.
O hook post-update que vem com o Git por padrão executa o comando apropriado (git update-server-info) para fazer uma busca HTTP e clonagem do trabalho propriamente.
Esse comando executa quando você envia para esse repositório (por SSH talvez); então, outras pessoas podem cloná-lo com algo como
$ git clone https://example.com/gitproject.gitNesse caso em particular, nós estamos usando o caminho /var/www/htdocs que é comum para configurações Apache, mas você pode usar qualquer servidor web estático – apenas colocando o repositório vazio (bare repository) nesse caminho.
Os dados do Git são disponibilizados como simples arquivos estáticos (veja ch10-git-internals.asc para mais detalhes sobre como exatamente eles são disponibilizados).
Geralmente você escolheria executar um servidor HTTP Smart de leitura/gravação ou simplesmente ter os arquivos acessíveis como somente leitura da maneira burra. É raro executar uma mistura dos dois serviços.
Nós vamos nos concentrar nos prós da versão Smart do protocolo HTTP.
A simplicidade de ter uma única URL para todos os tipos de acesso e ter o prompt do servidor apenas quando a autenticação é necessária torna as coisas muito fáceis para o usuário final. Ser capaz de se autenticar com usuário e senha é também grande vantagem sobre o SSH, já que usuários não precisam gerar uma chave SSH localmente e fazer upload de sua chave pública para o servidor antes de ser capaz de interagir com ele. Para usuários menos sofisticados, os usuários de sistemas onde SSH é menos comum, esta é a maior vantagem na usabilidade. Ele também é um protocolo muito rápido e eficiente, parecido com o próprio SSH.
Você também pode disponibilizar seus repositórios somente-leitura por HTTPS, que significa que você pode encriptar a transferência de conteúdo; ou você pode ir mais longe e fazer os clientes usarem certificados SSL assinados específicos.
Outra coisa legal é que HTTP/S são protocolos tão comumente usado que firewalls corporativos costumam ser configurados para permitir o tráfego por essas portas.
Por HTTP/S o Git pode ser um pouco complicado para configurar comparado com alguns servidores SSH. Fora isso, há muitas pequenas vantagens que outros protocolos tem sobre o protocolo HTTP "Smart" para servir o Git.
Se você está usando HTTP para envios autenticados, inserir suas credenciais é algumas vezes mais complicado que usar chaves por SSH. Há contudo várias ferramentas para armazenar credenciais que você pode usar, incluindo o acesso por Keychain no OSX e o Gerenciados de Credenciais no Windows, para fazer isso bastante indolor. Leia ch07-git-tools.asc para ver como configurar um gerenciador de credenciais no seu sistema.
Um protocolo comum de transporte quando o Git está auto hospedado é o SSH. Isso é porque o acesso SSH para servidores já é configurado na maioria dos lugares – e se não for, é fácil fazê-lo. SSH também é um protocolo de rede autenticada; e por causa disso ele é onipresente, ele é geralmente mais fácil de configurar e usar.
Para clonar um repositório Git por SSH você pode especificar a URL ssh:// assim:
$ git clone ssh://user@server/project.gitOu para encurtar você pode usar a sintáxe scp para o protocolo SSH:
$ git clone user@server:project.gitVocê também pode não especificar o usuário e o Git assumirá que o usuário é o atualmente logado.
São muitos os prós de usar SSH. Primeiro, SSH é relativamente fácil de configurar – serviços SSH são comuns, muitos administradores de rede tem experiência com eles, e muitas distribuições de SO são configurados com eles ou tem ferramentas para gerenciá-los. Depois, acessar por SSH é seguro – toda a transferência de dados é criptografada e autenticada. Por último, como HTTP/S, Git e o protocolo Local, SSH é eficiente, compactando os dados o quanto possível antes de transferí-los.
O aspecto negativo de SSH é que você não pode usar acesso anômino ao seu repositório por ele. As pessoas precisam ter acesso à sua máquina por SSH para acessá-la, mesmo que seja em modo somente leitura, o que não torna o acesso SSH propício para projetos de código aberto. Se você está usando ele somente na sua rede corporativa, o SSH pode ser o único protococolo que você precisa para ligar com isso. Se você quer permitir acesso anonimo somente leitura para seus projetos e também quer usar SSH, você precisará configurar o SSH para você enviar, mas outra coisa para os outros buscarem.
O próximo é o protocolo Git.
Esse serviço especial vem empacotado com Git; Ele escuta uma porta dedicada (9418) que provê um serviço parecido com o protocolo SSH, mas absolutamente sem autenticação.
Para um repositório ser usado pelo protocolo Git, você precisa criar o arquivo git-daemon-export-ok – o serviço não usará o repositório sem que o arquivo esteja nele – mas não há qualquer segurança além disso.
O repositório Git estará disponível para todo mundo para clonar ou não está.
Isso significa que não haverá download por esse protocolo.
Você pode habilitar o acesso para envio; mas dada a falta de autenticação, se você você habilitar o envio, qualquer um na internet poderia encontrar a URL dos seus projetos e enviar para eles.
Basta dizer que isso é raro.
O protocolo Git geralmente é o protocolo de rende mais rápido disponível. Se você está usando muito tráfego para um projeto público ou trabalhando em um projeto muito grande que não requer atenticação dos usuários para acesso de leitura, é provável que você quererá definir um serviço Git para seu projeto. Ele usa o mesmo mecanismo de transferência de dados que o protocolo SSH, mas sem sobrecarga de criptografia ou atenticação.
A desvantagem do protocolo Git é a ausência de autenticação.
Geralmente, é indesejável que o protocolo Git seja o único acesso ao seu projeto.
Geralmente você o usará em conjunto com um acesso SSH ou HTTPS para alguns desenvolvedores que terão acesso para enviar e todos os outros usarão git:// para acesso somente leitura.
Ele também é o provavelmente o protocolo mais difícil de configurar.
Ele precisa executar seu próprio serviço, o que requer configuração xinetd ou similar, o que não é sempre fácil.
Ele também querer um acesso do firewall à porta 9418, o que não é uma porta que por padrão os firewall corporativos sempre permitem. Grandes firewalls corporativos normalmente comumente bloqueiam essa porta obscura.